ATL / WTL / STL

[High Class Asian Escort](http://www.independentasianangels.co.uk/)

I assume that the original 32-bit code used VB6-specific control elements, that the source code (text) for the RC file is unavailable, and that you are familiar with the .RC (source code for resources) file format. To my knowledge, there is no fully automated method of performing the conversion. What you must do is the following: 1. Extract the resources from the .EXE file using a resource file editor. I have used ResEdit (freeware) for examining resources in EXE files. IIRC, it can also extract resources from an EXE/DLL. 2. Convert any VB6-specific elements to generic Windows versions Each dialog etc. specifies its "class" type, which affects how it is displayed. This includes the DLL that must be loaded in order to display it. Convert any VB6-specific names to the generic equivalent (e.g. "VB6button" should be renamed "button", "VB6dialog" should be renamed "dialog", etc.) 3. EDIT: Some ActiveX controls may have no generic control that can replace them. In this case, you must decide whether to use a class library that supplies the missing functionality, or eliminate them from the file. 4. Recompile the RC file using the Visual Studio resource editor. You should get an application that has standard dialog boxes. It will presumably require lots of tweaking before the layout etc. looks OK, but it is a good starting point. Good luck! If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack. --Winston Churchill

IIRC you get this - or at least a similar - chain of warnings/errors when your first include does not match the precompiled header setting for the file. Check that the precompiled header setting for this file actually is "stdafx.h", not another one.

Sometimes you need both. For UTF-8 unicode I use std::string For UTF-16 unicode I use std::wstring

the problem is simple. The code sheep[0] = ba; should be sheep[0] = std::move(ba); Your first approach used the copy constructor to copy the unique_ptr this defeats the purpose unique_ptr. Also another issue is: Baa operator = (Baa&& param) should be Baa& operator = (Baa&& param)

If your program isn't huge, no reason to do this in an external library, that would definitely be the slowest and most (disk) space consuming method. I'd say string table would probably be fast, and as long as you don't have too many strings, it shouldn't be too costly. If you have a huge number of strings, you may start using up quite a bit of memory to support this, then the library method starts to become more appealing.

Further questions: - the window handle you feed into IsWindow: is it a handle inside your application or a different window? - is your application running elevated? - is the other application running elevated? - are there differences in 32 vs. 64bit architecture between the applications?

bkelly13 wrote: and they disdain C++. Thanks for clarifying Bryan; seems you really are the one with the tough part of the job. bkelly13 wrote: dropping WCHAR and going to wchar_t Indifferent really, as WCHAR is just a typedef for wchar_t, probably a hangover from the days before C++. I know that going from ASCII to Unicode is initially a bit of a pain, but it is probably the right decision for the long term.

Check the even log for the details.

What?! :confused: There are only 10 types of people in the world, those who understand binary and those who don't.

That was it. Thank you. Thank you for your time If you work with telemetry, please check this bulletin board: www.irigbb.com

See my better explanation below.

Daniel Pfeffer wrote: Richard MacCutchan wrote: If you make everything Unicode, you should not have any issues. It depends on what you mean by Unicode... Windows API and UI use UTF-16 (started with Windows-NT 4.0) but if you generate output for a SMTP/email/WEB you must use UTF-8. For UTF-16 you can use CStringW or std::wstring but for UTF-8 CStringA or std::string. UTF-8 is a multibyte string format but it has nothing to do with the old MBCS which depend on codepages. In this case using CSting depended on the UNICODE define to make the code UTF-16 aware is now out of time and can shoot you in the foot. Conversions between UTF-16 and UTF-8 can be done with the current MultiByteToWideChar and WideCharToMultiByte. But if you write more general software, do it with the stl: wstring_convert> converter; The bad thing is that the current C++ Visual Studio editor can't handle utf-8 string literals. It is a Windows application you know...

Ok, I am using that now, in stdafx.h Thank you for your time. Thank you for your time If you work with telemetry, please check this bulletin board: www.irigbb.com

Rainsey Long wrote: metro app I suggest you try the proper forum for metro questions.

I am hoping for that. Enough fumbling around in the dark. thank you for your help Richard. Thank you for your time If you work with telemetry, please check this bulletin board: www.irigbb.com