|
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
|
|
|
|
|
As mentioned above, const * char is meaningless. However char * const has meaning. As mentioned here[^], you have to read pointer declarations backwards.
const char * means a pointer to a character that is constant. The pointer can change but the data being pointed to cannot.
char * const means a constant pointer to a character. The pointer cannot change but the data can.
const char * const means a constant pointer to a constant character. Neither the pointer nor the data can change.
The C++ FAQ is a terrific place to learn all kinds of good stuff. Go here[^].
J
May the bear never have cause to eat you.
|
|
|
|
|
Thanks!
It helped a lot!
Cheers,
George
|
|
|
|
|
If you meant what's the difference between const char* and char const* , there is none, they're semantically identical.
--Mike--
I'm bored... Episode I bored.
1ClickPicGrabber - Grab & organize pictures from your favorite web pages, with 1 click!
My really out-of-date homepage
Sonork-100.19012 Acid_Helm
|
|
|
|
|
Thank you, Michael pal!
Cheers,
George
|
|
|
|
|
The first time Isaw this mentioned in MSDN is when you delete a menu item, but then it says you should call this function any time you change the menu. Just to be certain, this mens you call DRawMEnuBAr after anything like ModifyMenu , AppendeMenu etc? I didnt see it used in their sample code.....
Appreciate your help,
ns
|
|
|
|
|
OK, I may be guessing for some of this so take with a pinch of salt.
You need to call drawmenubar when a visual aspect of a menu (such as height, #items etc) that is in use by the system changes. For example, if you change the HMENU resource in use by your mainframe (for example, adding a new top level menu item) then you should call this so that the windows will correctly draw itself. If its a menu that is not in use by any window or is visibly being displayed (i.e as a popup) then you don;t need to call this as when the menu is finally used all the info will be upto date and the menu should show correctly.
Roger Allen
Sonork 100.10016
This is a multiple choice question, choose wisely
Why did the hedgehog cross the road?
A: To show he had guts?
B: To see his flat mate?
|
|
|
|
|
Okay> thanks. They didnt clarify that in MSDN, and your guess sounds plausible... . No wonder I didnt see it in their code samples illustrating submenu functionality...
Appreciate your help,
ns
|
|
|
|