Right, because I was not sure where this question belongs too.

Have you looked at this article? Version Tolerant Serialization The callbacks should be able to do what you need.

Abyss wrote: What is the preferred approach? If there was a preferred approach that applies in all circumstances, all other approaches would be dropped. I'd go for the simplest solution; meaning the OptionalField if I'd expect that the class is not going to change much. Anything that could have more/complexer versions, I'd write a custom ISerializable. Abyss wrote: However I expected that such kind of versioning is already implemented by the streaming framework. I tried to obtain the Assembly version from the SerializationInfo but it is always set to current version not to the version which was used when the object was saved. It'd be overkill, and not everybody will be wanting to use those version-numbers. Keep in mind that the version-number you see is the one of the assembly that the class is contained in. Alternatively, one might use different version numbers for files, created with a single version of a class. So, the one-size-fits all wouldn't fit here. Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]

It means: You designed the Software, and You wrote the Code, so You are the best person in the world to know what's it supposed to do or not do in the firstplace. None of us are in that priviledged position. :) Bram van Kampen

delete is a Keyword, NOT a global function :) Bram van Kampen

Naveen wrote: TrackPopupMenu will return 0 if user cancels the menu. Only if the TPM_RETURNCMD is specified. If not it will return the success or failure status. See the MSDN documentaion. If you specify TPM_RETURNCMD in the fuFlags parameter, the return value is the menu-item identifier of the item that the user selected. If the user cancels the menu without making a selection, or if an error occurs, then the return value is 0. If you do not specify TPM_RETURNCMD in the fuFlags parameter, the return value is nonzero if the function succeeds and 0 if it fails. To get extended error information, call GetLastError. - NS - [ODBaseBtn]

Abyss wrote: I did not expect that GetAsyncKeyState can handle mouse buttons as well. I didn't expect too. I accidentally saw that remark: sometimes luck helps... :laugh: :) If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile. [my articles]

Cool! Glad you found it! :) Abyss wrote: It does not matter if the DLL is MFC Extension or Regular DLL. In both cases it works fine. It will probably matter eventually - the initialization in the extension DLL is important to many of the MFC classes. It just depends which ones you use and where :) The CWinApp class is one of them - it's initialization in the DLL module is used with window/dialog creation for example. Mark "Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder

Why are you casting to the same type?

Finally, I found the problem. Well I simplified my problem so much. In my case the problem is somewhere else: A* ptr = new A; Then I incorrectly static casted the pointer to a C object: C* pObj = static_cast(ptr); because of this the dynamic cast failed in VC8, however in VC7 it works fine. pTest will be NULL in VC8 and in VC7 it will be ptr. A* pTest = dynamic_cast(pObj); I know the given approach is incorrect - why to cast to C object?! Just want to point out that VC8 is less tolerant... and this is good. On the other side in case of big projects the code migration to VC8 can cause big pains :mad: Thanks, Abyss

I continued with my investigation and found that if I copy the missing MFC80UD.DLL module from the WinSxS folder to the application's folder then the debugger shows the following: 'App.exe': Loaded 'C:\Out\App.exe', Symbols loaded. ... 'App.exe': Loaded 'C:\WINDOWS\WinSxS\x86_Microsoft.VC80.DebugMFC_1fc8b3b9a1e18e3b_8.0.50727.42_x-ww_c8452471\mfc80ud.dll', Symbols loaded. ... 'App.exe': Loaded 'C:\WINDOWS\system32\winspool.drv', No symbols loaded. Here the module not found message is displayed if the MFC module is not at app folder. 'App.exe': Loaded 'C:\Out\mfc80ud.dll', Symbols loaded. Well and I'm surprised, because the MFC module gets loaded twice. Can explain anybody why? Thanks, Abyss

Hi, I didn't know this method, but based on MSDN it loads the keyboard layout. I have to play with this maybe it will automatically translates the character to the local character... However user can switch to another languages. How can I catch this event? Or will Windows automatically handle this situation? It only requires to have the keyboard layout loaded to the application? Thanks for your help, Abyss

Abyss wrote: How can I determine that the clipboard content was dropped to the target window? I implemented a code which moves data between two application using the COleDropSource stuff. Since the data are moved (NOT copied) between the applications I need to know when can I remove the moved data from the source application. So the question is how to determine that the target application pasted/accepted the data from the clipboard (or the drag&drop finished) and it is safe to remove the source data. That’s not a very good design idea. What if I the end user of your app have important information on the clipboard? Here comes your app and whips it out. Your better off posting a user defined message from one app to the other to pass the data. Alternatively you can us IPC “Inter-Process Communication”. A Simple Wrapper for Sharing Data Structures Between Processes[^] Inter-Process Communication[^] ------------------------------- DEBUGGING : Removing the needles from the haystack.