|
TBBS_SEPARATOR indicates the use of an separator. Then it's size is widened to have place for inserting other elements. This is the common method for placing custom items like combo boxes etc. on a toolbar.
|
|
|
|
|
Ah! Thank you for clearing that!!!! I was really puzzled on this one!!
Appreciate your help,
ns
|
|
|
|
|
The release exe runs fine. The debug one crashes on:
CBKDoc * pDoc = (CBKDoc *)GetDocument();
pDoc->dynaMenuMap.clear();
where:
typedef std::set <CString> SubMenuSet;
typedef std::map <CString, SubMenuSet> DynaMenuMap;
;
THe very first time I entere the function, DynaMenuMap dynaMenuMap is empty, so perhaps clearing an empty map is a no-no? The release exe doesnt care....
How do I sidestep this?
Appreciate your help,
ns
|
|
|
|
|
int size = pDoc->dynaMenuMap.size();
if (pDoc->dynaMenuMap.size())
{
pDoc->dynaMenuMap.clear();
}
THe map starts out empty, and I clear only if its not empty....but now my debug version is saying size = some large neg number. All I have in the code mentioning the map untilk this point is DynaMenuMap dynaMenuMap in the .h file...
Appreciate your help,
ns
|
|
|
|
|
Are you certain it's crashing on the clear() call?
(It may be the case that pDoc is NULL, though I don't see why that would work in release but not in debug)
--
Help me! I'm turning into a grapefruit!
|
|
|
|
|
pDoc is not null . The size of the empty map is weird: some larege neg number. If I get rid of the clear(), it still crashes , but on the line in red!!!!!! If I put the clear(0 in it crashes on the clear()!!!!!!!!!!!
int size = pDoc->dynaMenuMap.size();
if (pDoc->dynaMenuMap.size())
{
pDoc->dynaMenuMap.clear();
}
<code>SubMenuSet & subMenuCat = pDoc->dynaMenuMap["Cat</code>"];
//crashes here if I comment out the clear()
size = -125......
Appreciate your help,
ns
|
|
|
|
|
ns wrote:
The size of the empty map is weird: some larege neg number
No;P Its just unsigned int .
You can use dynaMenuMap::size_type as type for your size results, but in the current implementation, this is just typedef ed to unsigned int .
Personally, I use size_t , AFAIK defined by Microsoft to be unsigned int .
Less typing as 'unsigned int ', and conveyes a meaning.
<edit> Something must be rotten with your doc-pointer.
My opinions may have changed, but not the fact that I am right.
|
|
|
|
|
I guess its the pointer...but what can I do?
In a view class where I generate the map:
unsigned int size = pDoc->dynaMenuMap.size();
with unsigned, I still get a non zero number --- large positive!!! Theres been no map created so far!!! So it should be zero!
But in the doc class whose member the map is:
BOOL CBKDoc::OnNewDocument()
{
if (!CDocument::OnNewDocument())
return FALSE;
CString abc;
abc.Format(" size of map in doc is %d", dynaMenuMap.size());
AfxMessageBox(abc);
return TRUE;
} retiurns size of zero!!! As it should...
Appreciate your help,
ns
|
|
|
|
|
Hi ns, most likely pDoc is not a valid pointer: check if other members of this object hold consistent values.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
What he said...
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
Pardon me? I don't get what you mean.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
Whoops, I guess that is a colloquialism.
I basically said I agree with you on all counts.
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
OK Excuse my poor understanding, I'm not a native English speaker and I guess it shows.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
This is really really upsetting!! I went and put in a member int testing variable in the doc (like you suggested) , and retrieved it in the offending view with the pDoc->. That came out fine! The next line was my size(). Now this came out 0!!!! Like it should be. Then the program ran perfectly in debug. SO I went and undid the addition of the int test variable in doc, and viola!!!! it still works perfectly. I am really puzzled and mistrustful now.....it bothers me when things get fixed miraculously...........
I am nonplussed!
Appreciate your help,
ns
|
|
|
|
|
You'd be better of testing it with the empty() function instead of size()
~RaGE();
|
|
|
|
|
I'm betting this is due to the cast on the document pointer. Didn't you add that GetDocument member I told you about? On a more serious note, you shouldn't have to cast that document pointer. I spent 2 weeks debugging a similar problem a couple years ago, where the compiler wasn't generating the correct address for the pointer because I was doing a "C" style cast. This would explain your "garbage" number, and (partially) the fact that adding a variable to the class solved the problem. If you are worried about it, try doing a "Build->Clean" on the Debug build, and run it again. If it fails, you're still in trouble.
Chris Richardson
Programmers find all sorts of ingenious ways to screw ourselves over. - Tim Smith
|
|
|
|
|
Yes. I did add the GetDocument to my second view. That was the first thing I did since you told me about it. If you are saying that its not good to do:
CBKDoc * pDoc = (CBKDoc *)GetDocument();
, then what should one do? I've always seen it this way. This is the cast you are talking about right? Are you saying that I should just do:
CBKDoc * pDoc = GetDocument();
since it returns the right thing anyways? It does the cast too......(CBKDoc*)m_pDocument
CBKDoc* CSearchView::GetDocument()
{
ASSERT(m_pDocument->IsKindOf(RUNTIME_CLASS(CBKDoc)));
return (CBKDoc*)m_pDocument;
}
#endif //_DEBUG
Appreciate your help,
ns
|
|
|
|
|
I'm write a application with two threads which are sender and receiver to send and receive data :
//Global
CSocket send_sock, recv_sock;
//These two sockets were created some where at start up
//before creating two threads : sender and receiver
// send_sock.Create(0, SOCK_DGRAM);
// recv_sock.Create(1111, SOCK_DGRAM);
//Sender thread
int sender(LPVOID)
{
while(bFlag)
{
//Some code here
send_sock.SendTo(data, size, port, addr);
//Some code here
}
}
//Receiver thread
int receiver(LPVOID)
{
while(bFlag)
{
//Some code here
recv_sock.ReceiveFrom(data, size, addr, port);
//Some code here
}
}
The sender runs ok but the receiver can not. The receiver just returns an error (WSAWOULDBLOCK) at the ReceiveFrom statement.
To solve this problem I use a socket variable as a local variable in the receiver function :
int receiver(LPVOID)
{
CSocket sk;
sk.Create(1111, SOCK_DGRAM);
while(bFlag)
{
//Some code here
sk.ReceiveFrom(data, size, addr, port);
//Some code here
}
}
So it runs ok in the 'Share MFC DLL' compile mode, it can not run in the 'Static MFC DLL' compile mode.
I don't know why because I'm starting with Window Socket.
So many problems to me. Please help me. Thanks in advance.
|
|
|
|
|
I think the program requires winsock DLL that the compiler will not assemble as static.
Kuphryn
|
|
|
|
|
You can't have two "sockets" using the same port at the same time. That's why it's blocking.
------- signature starts
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
Please review the Legal Disclaimer in my bio.
------- signature ends
|
|
|
|
|
But they are not in the same port.
The former : send_sock.Create(0, SOCK_DGRAM);
The later : recv_sock.Create(1111, SOCK_DGRAM);
If the method of using local socket variable in the receiver thread core is applied, I do not create the recv_sock. Thus, there are nothing in the same port.
Another question : how to configure the linker to link the winsock dll as static, not dynamic ?.
|
|
|
|
|
TPN wrote:
Another question : how to configure the linker to link the winsock dll as static, not dynamic ?.
I believe that you simply find the .lib file on the MSVC installation CD. I can't quite recall but I think that is how. Borland used to have a utility that would create a library file from a dll called, ImpLib. But, I am not sure that MSVC has one.
|
|
|
|
|
Who can give me a sample?
Thanks in advance.
George
|
|
|
|
|
The difference is that one wouldn’t work--declaring a const * char would give you an error. The compiler, VC6 anyway, would interpret it as a pointer to a constant int, named char. The reason it would crap out is because you can't use keywords as variable names.
cheers,
-B
|
|
|
|
|
Thanks, Ben pal!
Cheers,
George
|
|
|
|