|
Im not sure if I understand your question 100% but here is how I load a menu for my view... maybe it will help you out.. You could create different menus for each doc or view you have and load them like this..
void CMyView::OnRButtonUp(UINT nFlags, CPoint point)
{
ClientToScreen(&point);
CMenu menu;
menu.LoadMenu(IDR_POP_UP_VIEW);
CMenu* pPopup = menu.GetSubMenu(0);
CWnd* pWndPopupOwner = this;
while(pWndPopupOwner->GetStyle() & WS_CHILD)
pWndPopupOwner = pWndPopupOwner->GetParent();
pPopup->TrackPopupMenu(TPM_LEFTALIGN,
point.x, point.y, pWndPopupOwner);
CRichEditView::OnRButtonUp(nFlags, point);
}
|
|
|
|
|
Thank you but I was trying to make changes to the main menu at the top of the application, not a pop-up menu. As it turns out, the solution was simple but a little obfuscated. I had to delete and reload the menu data each time the child frame activated by using GetMenu() called from the main window, not the child frame, and it had to be done when the child frame was activated, not when the child frame's view class was activated, using the ON_WM_MDIACTIVATE event or else I'd wind up getting the menu used when there are no documents instead of the menu for documents. So I had been using the right functions just not in the right places or at the right moment.
|
|
|
|
|
CMultiDocTemplate* pDocTemplate;
pDocTemplate = new CMultiDocTemplate(
IDR_TYCATTTYPE,
RUNTIME_CLASS(CTycattDoc),
RUNTIME_CLASS(CChildFrame), // custom MDI child frame
RUNTIME_CLASS(CTycattView));
AddDocTemplate(pDocTemplate);
// create main MDI Frame window
CMainFrame* pMainFrame = new CMainFrame;
if (!pMainFrame->LoadFrame(IDR_MAINFRAME))
return FALSE;
m_pMainWnd = pMainFrame;
::DestroyMenu(pDocTemplate->m_hMenuShared);//=pMainFrame->NewMenu();
// pDocTemplate->m_hMenuShared = NULL;
pDocTemplate->m_hMenuShared = pMainFrame->GetMyMenu();
GetMyMenu() prepare your new menu handle
I am seeking...
For what?
Why did you ask me for what? I don't know!
|
|
|
|
|
Hi, apparently, no-one seems to be able to answer my question on newsgroups because I guess it's more complicated than rocket science.
I'll make this real simple. Suppose I have one modeless dialog called, CFirstDialog that gets displayed from the document class upon a menu selection. In the CFirstDialog class, I have an on OnOK handler:
void CFirstDialog::OnOk()
{
// I simply wish to open up another modeless dialog box upon closing this one
m_mySecondDialog = new CSecondDialog(this);
m_mySecondDialog->Create(CSecondDialog::IDD, this);
m_mySecondDialog->ShowWindow(SW_SHOW);
// Calling DestroyWindow destroys this dialog, so the second dialog
// will show, but it will show only for an instant obviouly because
// it's a member variable that gets destroyed when this object is destroyed.
DestroyWindow();
}
How do I make CSecondDialog show up while at the same time closing CFirstDialog? If I don't call DestroyWindow, but say, call EndDialog, then there's a memory leak since it's modeless, but calling DestroyWindow will not enable the second modless dialog to stay created. I know that I could just merely have the document class (the one that opened up CFirstDialog to begin with) open up CSecondDialog, but this would require a bit of strange logic, like setting variables in CFirstDialog to signal that it's closing so that the document class can therefore open up CSecondDialog, but this would require goofy logic, but is this basically the only way? Can anyone please tell me how to solve this tougher than rocket science problem?
|
|
|
|
|
One solution is to show the modeless dialog box after the modal dialog box returns from DoModal().
Kuphryn
|
|
|
|
|
The problem is that both dialogs are modeless.
|
|
|
|
|
You could create a function in your main application to create the second dialog box.. Then in your first dialog OnOK() PostMessage or SendMessage to the main application telling it to launch the second dialog..
Rob
|
|
|
|
|
Heres another option.. Its not as good as the first one but its much easier...
In your OnOK dont close the dialog just HIDE it and show the second dialog box..
In your Second Dialogs INIT() do a..
// Kill the 1st dialog..
CWnd *pOtherWnd = CWnd::FindWindow(NULL, _T("Dialog 1 Title.."));
if (pOtherWnd)
pOtherWnd->PostMessage(WM_CLOSE);
|
|
|
|
|
Hi Rob Jones! THANK YOU VERY, VERY, VERY MUCH MAN!!!!!!!!!!!!!!
Joey
|
|
|
|
|
Hi all,
Has anyone ever experienced or read of a problem where ::HttpSendRequest hangs on the INTERNET_STATUS_RECEIVING_RESPONSE status event?
I am experiencing this problem intermitently in an application that I have written. I am using WININET syncrhonously an I have enabled the status callback, that is how I know the function is hanging at the INTERNET_STATUS_RECEIVING_RESPONSE event.
My app will appear to work fine for quite a while, but then the thread that calls ::HttpSendRequest will hang. I detect this with a second thread to implement the timeout test as MSDN reports that this is the only reliable way to handle timeouts for versions of IE older than 5.5. After I detect the timeout, no requests work properly after that point until I restart my app.
If anyone has insight to this I would really appreciate it.
Thank you.
Build a man a fire, and he will be warm for a day
Light a man on fire, and he will be warm for the rest of his life!
|
|
|
|
|
That's why I use Winsock.
Todd Smith
|
|
|
|
|
What about HTTPS support?
Do you have any experience with that? Is it as simple as using the SSL functions instead of the regular socket functions?
Thanks
Build a man a fire, and he will be warm for a day
Light a man on fire, and he will be warm for the rest of his life!
|
|
|
|
|
yep. But this depends on what are you doing - e.g. for client side apps the wininet is quite OK, but when talking about 24/7 apps it is better to use the pure winsock stuff + say few hundred lines for SSPI usage.
And once you have some other SSL support(I think there are some on codeproject or look for OpenSSL or others) I will stick to it and don't want to see wininet any more in my life 
linx:
SSL/TLS client/server for .NET[^]
CSSLSocket[^]
|
|
|
|
|
I've often wondered what is the reasoning behind passing structs by pointers rather than by reference. Can anyone give me a good motivation for choosing one over the other? I see it all the time in MFC -- is it just MS standard?
For instance, if I have the following:
typedef struct POINT
{
double x;
double y;
} tagPOINT, *LPPOINT;
void GetCurrLoc(LPPOINT pt)
{
pt->x = 3.2;
pt->y = 2.4;
}
void GetCurrLoc(POINT& pt)
{
pt.x = 3.2;
pt.y = 2.4;
}
Is one any better than the other, besides the fact that passing by pointer is (slightly) easier when using dynamically allocated structs.
Thanks,
Dean
|
|
|
|
|
when passing objects ( struct ) by pointer, you always need to check the incoming pointer for NULL.
if you pass by reference, you are sure that the class/struct is valid.
Max.
|
|
|
|
|
I'm sorry, but that is a false statement. Look at this code:
struct SomeStruct { ... };
SomeStruct& func() {
SomeStruct s;
return s;
}
void func2(SomeStruct& s) {
s.DoTheFunkyStuff();
}
func2(func());
So, just because it's a reference doesn't guarantee its validity.
I feel that references are in the C++ language because it's syntactic sugar. I have no proof of this being the case, but I just can't find any other reasonable explanation for it.
--
Only in a world this sh*tty could you even try to say these were innocent people and keep a straight face.
|
|
|
|
|
Returning a reference to a object declared on the stack in a function is wrong and bad coding! and will generate a very basic compiler warning ( level 1 ):
It's only a warning because ( I think ) references are implemented as pointers.
from MSDN :
Compiler Warning (level 1) C4172
returning address of local variable or temporary
A function returns the address of a local variable or temporary object. Local variables and temporary objects are destroyed when a function returns, so the address returned is not valid.
Redesign the function so that it does not return the address of a local object.
Max.
|
|
|
|
|
Yes, and so is using a pointer to a previously deleted object.
It is bad yes, but it is still possible. Thus you can't rely on references being always correct.
I know my example was trivial and is obviously erroneous, but I'm still right 
--
There's a new game we like to play you see. A game with added reality. You treat me like a dog, get me down on my knees.
We call it master and servant.
|
|
|
|
|
Or what about this one?
class SomeClass {
RefClass& ref;
public:
SomeClass(RefClass& ref_) : ref(ref_) { ... }
};
.... somewhere in 10<sup>6</sup> lines of code ....
RefClass* pRef = new RefClass();
SomeClass* pObj = new SomeClass(*pRef);
.... somewhere else among those 10<sup>6</sup> lines of code ....
delete pRef;
See what I mean? SomeClass::ref isn't valid. Yes it's a bug, but you can't say that ref is valid after the delete pRef. Same thing goes for pointers to object. Just because a pointer is not NULL doesn't make it valid. That's a dangling pointer, and as you can see, there are also dangling references. In both cases you have a bug on your hands, but it still doesn't make your previous statement true, which was my main argument all along.
BTW, you can do this in VS.NET and most likely VC6:
struct Test { int x; };
int _tmain(int argc, _TCHAR* argv[])
{
Test& ref = *((Test*)NULL);
return 0;
}
No crash, no nothing. Yet, ref will reference "an object" at NULL. Put a breakpoint on return 0 and you'll see.
I still believe that the only advantage of references over pointers are purely syntactical.
--
There's a new game we like to play you see. A game with added reality. You treat me like a dog, get me down on my knees.
We call it master and servant.
|
|
|
|
|
That is a bug in the program which is a different beast. As the standard states, a well defined program can't have a NULL reference where a pointer can have a NULL pointer.
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
Yes, it was a bug - and what software is 100% bug free?
Tim Smith wrote:
As the standard states, a well defined program can't have a NULL reference where a pointer can have a NULL pointer.
True. But just as pointers can be dangling, references can too as I demonstrated.
NULL is just one "bad" value out of 232 possible values on a contemporary 32 bit machine. Most of the other 232 - 1 aren't (most likely) legal.
I am arguing that the statement "if you pass by reference, you are sure that the class/struct is valid" is false - something which I believe I demonstrated with perhaps an easy to spot "error". However, as you point out, a reference can't ever be NULL1.
1 In an environment where you can do *((SomeClass*)NULL) = SomeClass();, what is SomeClass& ref = *((SomeClass*)NULL);? You could, if you really wanted to, do that in DOS.
--
There's a new game we like to play you see. A game with added reality. You treat me like a dog, get me down on my knees.
We call it master and servant.
|
|
|
|
|
It certainly is possible to pass a reference to NULL:
struct Stuff {
...
};
void StuffFunction(Stuff &stuff_item);
...
Stuff *stuff_pointer = NULL;
StuffFunction(*stuff_pointer);The compiler treats the "reference to dereferenced pointer" object as an 'identity' case, and just passes the value of the pointer, which in this case is NULL. In this case, inside the StuffFunction you can't tell that NULL has been passed in.
The point behind the debate is that references are not inherently 'safer' than using pointers. They can be syntactically more convenient. Pointers are easier to get sloppy with if you're not careful.
Software Zen: delete this;
|
|
|
|
|
Gary R. Wheeler wrote:
It certainly is possible to pass a reference to NULL:
I know, I tried it in VS.NET the other night.  I was just too tired to mention it, and it didn't really have any relevance with respect to my argument.
Gary R. Wheeler wrote:
In this case, inside the StuffFunction you can't tell that NULL has been passed in.
Well, you could always do if(&stuff_item == NULL), assuming Stuff doesn't override operator&.
Gary R. Wheeler wrote:
Pointers are easier to get sloppy with if you're not careful.
The only extra support a reference gives you is that you have to initialize it. Which is certainly nice since the compiler can yell Error!
I think I'll experiment some tomorrow to see if I can eliminate the use of pointers (to see if it's possible). I have some ideas I want to try out...
--
There's a new game we like to play you see. A game with added reality. You treat me like a dog, get me down on my knees.
We call it master and servant.
|
|
|
|
|
When using non-dynammically allocated structures or when accessing elements of an array, the reference version is easier and visually cleaner. Also, it would be wise to place consts on both those arguments to provide hints to the compiler.
References really start to shine when you start getting into operator overloading.
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
Ah yes, lpObject->operator[](index) is rather ugly, huh? So as far as I can see, there is no real reason to use one over the other, other than for cleanliness of the code. As for the consts, I got you on that one -- neither can be const since they are both modified by the called function. 
Thanks everyone for the responses.
--Dean
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
