That's a tray icon which has nothing to do with whether your application is minimized or not.
When you called Shell_NotifyIcon you had to specify a callback message in the NOTIFYICONDATA struct right? The lParam of that message would contain the mouse or keyboard message associated with the event.
Your app has to have the input focus in order to handle mouse messages. When your app is minimized it does not have the input focus. The only work around that I know of is to setup a global hook. See SetWindowsHookEx(WH_MOUSE, ...) in MSDN and do a search here on CP for "Global Hooks"
I have a quick question about serialization. I have a custom built classe (we'll call it MyClass) that contain standard C++ items (i.e. int, float, etc...), MFC objects (i.e. CString, etc...), a few vectors, and some of my custom classes as data memebers. If I derive it (MyClass) from CObject, can I use the standard MFC Serialize functions to save it (MyClass) to a file?
yes what i meant was that MFC callback function is in a DLL and I can call other functions (not callback) from my calling program (non mfc dll) without any problem.
but when my non mfc dll tries to invoke the callback it doesn't get called
the same thing when called from an MFC program works fine.
So my question was is there some thing different that i need to do when i call it from a non mfc app?
like may be sometime of memory mapping? is there any sample code that i can look at?
yes it seems like it steps over
When i try to go in to the assembly code it show me a ref to the callback function but doesn't jump to it. instead it comesback to my calling functions next statement.
I don't get any exception.
Also I cut and pasted the same code into another applicaiton (MFC) and it works without any problem.
In VC6, I could insert a copy of an existing dialog and for which a class has been created, and then with the dialog editor I could add new controls on this copy and add event handler and variables for these new controls. In VC++.NET 2003 it does not seem to work. I can add a copy but after I add new controls on this dialog copy I cannot add events or variables to them because they are not listes in the Control Events in the properties page.
Steps to reproduce:
1) create a dialog (default template will be enough)
2) Create a class for this dialog
3) Right the dialog in the resource view and select 'Insert Copy', you will have to enter a valuee in the condition field, for example 'TEMP'
4) Add an edit control to this copy of the dialog template
Now, if you right click the edit control and select 'Add variable, the wizard will not have the proper control ID filled in. Also, if you go in the Properties of the dialog and select the Vontrol Events view, the ID for the edit control will not show up.
I had no problem doing this in VS6.
Anyone seen this problem and know a workaround ?
Can anyone tell me if it does the same thing in VS.NET 2005 ?
in 2005 after you copy the dialog into the resource tree you open it in the disigner, right click and choose the "Add Class" menu item. This brings up the dialog where you can add a class derived from CDialog bound to the dialog resource. After you do that adding controls and member variables work as expected.
WARNING: Copy / Paste pattern is generally not a good development approach.
"Just about every question you've asked over the last 3-4 days has been "urgent". Perhaps a little planning would be helpful?" Colin Angus Mackayin the C# forum
Last modified: Friday, July 14, 2006 11:13:07 AM -- copy / paste warning
My example was for a simple dialog. My situation, and I guess this is something many other programmers have to face, is that I have dialogs that already have a working class with all the code and variables and event handlers doing their stuff. Now, I am adding a copy for this same dialog to add features to it, so logically I will want to use the same code that is already there. The compile condition I add to the dialog copy makes it available only when I compile resources with this condition set. I can add code to the dialog that will also be conditionnaly compiled with the same condition. This makes adding new features to a dialog easy and also is more team friendly.
You are suggesting to add a completly new class to the dialog. This would involve copying all the source from the other class to this new class and then adjusting the class name to match the new. If a modification is done to the original dialogs code (team) it will not be reflected in this class.
Why a copy of a dialog resource would not be a good devcelopement approach ?
* google is your friend *
Last Visit: 31-Dec-99 19:00 Last Update: 30-Nov-23 7:49