|
Nibu thomas wrote: Will this work with class objects.
Yes it will. Basically, new is responsible for allocating memory, and the compiler is responsible for calling the constructor. Same with delete - the compiler ensures the destructor is called before delete is.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
yes, it will work, but very badly... in fact it wont always work because malloc() and other C-style memory allocation functions are non-reentrant. so, this can come to some memory leaks...
i just don't understand why you advise him to use malloc() inside his overloaded new.
why not simply using ::new which refers to the global new (the one defined bu the compiler).
|
|
|
|
|
v2.0 wrote: why not simply using ::new which refers to the global new (the one defined bu the compiler).
Yes, I think that to.
regards
hint_54
|
|
|
|
|
Ryan Binns wrote: Do you need to be able to call the old version?
Yes, I do. The overloaded version of the operator should be inside a namespace. So I could do:
CSomething *p;<br />
p = new CSomething;
p = nMyNamespace::new CSomething;
<br />
{
using namespace nMyNamespace;<br />
p = ::new CSomething;
p = new CSomething;
}
Ryan Binns wrote: Just make sure you overload delete as well, to call free()
I've read somewhere that operator new expands to a call of malloc() and that delete expands to free(). But I'm not shure where that was or if it was a reliable source. So, for now i'll stick to calling the global version of the operator from inside the overloaded version.
regards [[]]
hint_54
|
|
|
|
|
hint_54 wrote: I've read somewhere that operator new expands to a call of malloc() and that delete expands to free()
Yep. It does in the implementations that I've investigated. That's why I suggested it.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
I have a problem. In MFC, on a Dialog box, if a combo box shows dropdown list and user hits the Cancel button Dialog does not close immediately. It closes the Dropdown list ignoring the cancel button.
User has to push cancel button one more time to close the Dlg.
How can I make it close the dialog immediately?
Tahir Helvaci
|
|
|
|
|
Intercept the WM_KEYDOWN message in PreTranslateMessage() of your application class and check for ESC (i.e. 27) as parameter value. Then post a WM_CLOSE or a WM_QUIT to your main dialog window.
if (pMsg->message == WM_KEYDOWN)
{
switch (pMsg->wParam)
{
case 27:
PostQuitMessage(0);
return FALSE;
}
}
SkyWalker
|
|
|
|
|
Thanx for the reply but I wanna use mouse to click cancel button on the dialog box, not the keyboard.
THelvaci
|
|
|
|
|
Oh, sorry for understanding you wrongly.
Intercept then the mouse click.
SkyWalker
|
|
|
|
|
thelvaci wrote: if a combo box shows dropdown list and user hits the Cancel button Dialog does not close immediately. It closes the Dropdown list ignoring the cancel button.
User has to push cancel button one more time to close the Dlg.
How can I make it close the dialog immediately?
Yeah it happens. I guess it's so because when the combo list box comes up it captures the mouse(Using SetCapture ).
And now events that occur related to mouse will be relayed to the list box.
This is done so that the list box can be properly closed if the user clicks anywhere outside the list box. Now when the listbox closes it calls ReleaseCapture .
This is the reason why the cancel button doesn't get the mouse event when the list box is visible. But second time it does get.
Nibu thomas
Software Developer
|
|
|
|
|
Thanx for the reply.
I can give you an example: MS Word program File->Open->
In the File Open Dialog box you hit the combobox on top to open the directory tree. Dropdown list opens. Now when one hits the cancel button the drop down list closes immediately and this closes the file dialog.
How is this done?
Rgds
Tahir Helvaci
|
|
|
|
|
I wouldn't recommend trying to do this. It will make your application behave differently to every other Windows application in existance. Combo boxes work this way by design.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
Thanx for the reply.
I can give you an example: MS Word program File->Open->
In the File Open Dialog box you hit the combobox on top to open the directory tree. Dropdown list opens. Now when one hits the cancel button the drop down list closes immediately and this closes the file dialog.
How is this done?
Rgds
Tahir Helvaci
Thelvaci
|
|
|
|
|
Yes, I'd forgotten about MS Office. So Office and your program would be the only ones like it in the world. Almost all applications use the standard Windows File open common dialog box, which does not do this.
Personally, I still think it's a bad idea. I'm not sure what the best way to do it would be. There would be a few complications in getting it right.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
How about the challenge?
thelvaci
|
|
|
|
|
Hello thelvaci
To close dialog immediatly, in the function associated with Cancel, write the following line.
CDialog::OnOK();
I hope this works.
Good luck.
We Believe in Excellence
|
|
|
|
|
Aqueel wrote: in the function associated with Cancel, write the following line.
CDialog::OnOK();
You should not call CDialog::OnOK() from OnCancel() but in fact you should call CDialog::OnCancel() .
Nibu thomas
Software Developer
|
|
|
|
|
actually, OnOK() and OnCancel() bothe call EndDialog() with either IDOK or IDCANCEL as parameter for the returning value of the dialog.
the difference comes because only OnOK performs an UpdateData(TRUE) , so updates the data members of the dialog when the ok button is clicked.
you can so directly call yourself EndDialog(IDCANCEL) , it will work perfectly.
however, this is not exactly what the question was about ...
|
|
|
|
|
Right thing in the wrong place.
Nibu thomas
Software Developer
|
|
|
|
|
Nibu thomas wrote: in the wrong place.
how that ?
i answered to you because i wanted to continue the discussion you started with Aqueel...
|
|
|
|
|
v2.0 wrote: how that ?
i answered to you because i wanted to continue the discussion you started with Aqueel...
You misunderstood.
What I meant was CDialog::OnOk was called at the wrong place.
Nibu thomas
Software Developer
|
|
|
|
|
CDialog::OnCancel() closes the dialog.
The problem in the first place is to have the combobox drop down list to close at the same click of cancel button as in MS Word open filoe dialog and opening the drop down list, when one click on the cancel button it closes the whole file dialog, it does not close just the combobox dropdown list.
It seems that this is a challenge for all the MFC programmers...
thelvaci
|
|
|
|
|
Greetings:
Can anybody offer some advice on how I can dynamically change the bitmap on a toolbar button? I would like a toolbar button that has a bitmap that means "Open" (refering to a USB port). When the user clicks this and the port is successfully opened, I want the bitmap on the button to change to one that means "Close" - and vice-versa of course. This is just one example, there are many places in my application where I might want to do something like this.
I was hoping that it would be something I could do from within the "ON UPDATE UI" procedure associated with the button but its not looking good. So I am unsure how to proceed...
Thanks in advance to anyone who responds.
Mark
|
|
|
|
|
CImageList *img;
m_wndToolBar.GetToolBarCtrl().SetImageList(img);
|
|
|
|
|
Hi, thanks for your response.
When I set the image list, does this refer to just the image for one button? My understanding is that the toolbar gets its button images from a single BMP image "strip". If this is the case, then it looks like I would have to repeat the image "strip" for each button that has two image states.
If I had a tool bar that had only one button that behaved in the way that I described, then I would need only two image strips. However, if TWO buttons on my toolbar toggled between two images, then I would need FOUR image strips to cover every possible permutation. If there were 3, then EIGHT! And so on...
Have I understood this?
Thank you,
Mark
-- modified at 15:16 Wednesday 8th March, 2006
|
|
|
|