In older version of Borland C++Builder you used the Console Wizard to start off a Win32 program. That is now gone from XE5! How do I start??
The wizard you are looking for is located at:
File > New > Other ... > C++Builder Projects > Console Application
However, the wizard dialog has been broken since XE2 and is still not fixed in the latest version (XE7 at the time of this writing).
The dialog has a drop-down list to select a "Target Framework". If you set this to "None", you may get "unresolved external" errors at link-time. So you might have to choose either "Visual Component Library" or "FireMonkey".
The dialog has a "Console Application" checkbox that is checked by default and disabled from user interaction.
As such, you can only create a console app that uses a main() entry point, rather than a Win32 app that uses a WinMain() entry point. Fortunately, there is a workaround in the Registry:
HKEY_CURRENT_USER\Software\Embarcadero\BDS\<version>\Repository\New Console Application
(REG_SZ) "ConsoleApp" = "True" or "False"
Set "ConsoleApp" to "True" or "False" to specify the checkbox's default state. By setting it to "False", you can create a console app that uses a WinMain() entry point.
Alternatively, another way to create a Win32 app with a WinMain() entry point is to create a new VCL Forms Application and remove the default generated MainForm from the project and remove any code you don't want from the default generated WinMain().
Embarcadero is aware of the bugs (I have discussed it with them in private, and they have confirmed there are some oddities in the dialog's code that are causing this issue). I don't see any QualityCentral tickets for them, so I have now submitted a QualityPortal ticket.
RSP-10796 C++ Console Application wizard is broken
Hopefully they will finally get fixed.
Related
I'm working on a Xamarin Forms app, using a .NET Standard library. I've used the TranslateExtension as mentioned in the docs. I've added three resource files:
AppResources.resx (with matching code-behind file, auto-generated)
AppResources.nl.resx (Dutch translations)
AppResources.fr.resx (English tranlations)
When debugging the (UWP) app, I can't get the default culture (English) to be displayed. The following line returns null:
ResMgr.Value.GetString(Text, ci);
I've add some lines for debugging, and the other two languages do return the translated value:
ResMgr.Value.GetString(Text, new CultureInfo("nl")); // OK
ResMgr.Value.GetString(Text, new CultureInfo("fr")); // OK
ResMgr.Value.GetString(Text, new CultureInfo("en")); // returns null
What could possibly be the cause of this?
Things I've tried:
I've copy-pasted the key across all resource files, so I've ruled out misspelling the resource key.
I've tested "en-GB", "en-US", CultureInfo.InvariantCulture.
I've changed the default lanuage in the appxmanifest from en-US to en.
On UWP, watch that your resource name does not have a period in it..
You also likely need to tell the UWP project what its default language is. This can be done in the .csproj in the top <PropertyGroup> element (the one with no conditions) by adding <DefaultLanguage>en-US</DefaultLanguage> (using the proper culture for your scenario).
Don't forget to set the [assembly: NeutralResourcesLanguage("en-US")] as well for the assembly containing the resources - this is required for .NET Standard 2.0 and likely PCL.
Well it seems like you've got resx files for "nl" and "fr" (which you've said works fine) but you don't have one for "en". If you're trying to get the English value like that, I would think you need an "en" file the same way you do for "nl" and "fr"
I noticed that you told about NET Standard library
ResourceManager.GetString started giving null for new entries after moving from PCL to .NET Standard
I also observed that the file AppResources.Designer.cs disapeared from the Solution Explorer (but I don't know how, was still considered) and, in the VS res editon of AppResources.resx, Access Modifier was No Code Generation.
Here is what I did to fix that:
I double-clicked on AppResources.resx and set Access Modifier to Internal or Public
In .NET Standard you may no longer be able to see "View Code" from resx files; so, I righ-clicked on AppResources.resx-> Open With -> Source Code Editor and copy the new created entries to all the others *.fr (also *.nl in your case) ...
NOTE
In the context menu you should see Run Custom Tool. You may need to delete the old AppResources.Designer.cs and do "Run Custom Tool"
Don't forget to clear the solution (or olny UWP and the standard library), close VS, delete all .\bin and .\obj and restart VS. This to ensure your issue is fixed or not using the very very new generated true code :)
I have to travel back in time and debug a VB6 form. It is used inside an application (not ours, Esri ArcMap.exe). I see VB6 has some debug capabilities, but nowhere do I see, like in .NET, the ability to "launch another app" or "attach" to a running application.
How can I debug my VB6 code while running inside a 3rd party application?
It's right there; you just didn't see it.
If your form is hosted inside a DLL (most likely from your description), you have two options, both of which can be set from the "Project"-> "Projectname Properties" dialog box, Debugging tab.
"Wait for components to be created"
When click on Run (F5), VB6 will alter the registry entries for your DLL so that they point to the VB6 debugger.
Launch your third-party program as usual.
When any program tries to create objects and forms hosted by your DLL, it will do so through the debugger.
"Start a program"
Same as before, plus VB6 will execute the command line entered in the dialog box.
It should be noted that VB6 must be run in full "As Administrator" mode, because it needs to write to normally-protected areas of the registry.
Don't worry about the third option. Let's just say that some things are better forgotten.
My first-hand knowledge is a little hazy (I've inherited a PC with all of this stuff configured, and I have no intention of ever setting it up again from scratch...), but here goes:
There is an ESRI VB6 add-in called ESRI Compile and Register, which is supposed to make this whole process a lot easier.
There's a lot of instructions on that link, but one of the key things is under Options->Support Visual Basic Debugger, which creates a file ESRIVBDebugHelper.exe.
In Project -> Properties -> Debugging tab, under Start Program, you enter the full path to this ESRIVBDebugHelper.exe. Then when you debug the VB6 application, it should spawn ArcMap and allow you to debug on the fly within the VB6 IDE.
We have an application built against MFC9 (VC2008).
The application is an SDI application, and shows a file open dialog during InitInstance(). Showing that dialog causes comdlg32.dll to be loaded. Some minutes later, the comdlg32.dll is unloaded automatically. After this, the next function depending on the DLL will crash.
How can this be avoided? What governs the automatic unloading/loading of the DLL?
Further info:
We don't see this problem on WinXP with the same application.
On Win7, this behavior only occurred since the beginning of this year - maybe some MFC update is related to this?
A small test application does not exhibit the problematic behavior - the comdlg32.dll is re-loaded when needed.
We’ve found a statement by Microsoft that it isn’t recommended to use modal dialogs in InitInstance() of MDI applications (http://support.microsoft.com/kb/173261) - we have an SDI application, though.
We don't directly use comdlg32.dll in any way, only indirectly through the MFC.
You have to call InitCommonControlsEx in your application on startup.
This will initialize the comdlg32.dll and also increase the reference count of the dll, so it won't get unloaded after closing a file-open/save dialog.
You don't say whether you customize your dialog or it is just a straight up file dialog. I think starting with Vista, the common file dialog was changed some. I know if you compare older MFC code with newer, you will see that the MFC code has been changed to take advantage of those changes. For instance, the IFileDialogEvents and IFileDialogControlEvents were implemented in MFC to support the way Vista and later versions of the OS customize file dialogs.
I don't know if I have an answer, but just for grins I would probably make sure I call AfxOleInitialize() sometime in InitInstance() before I tried to call the file dialog.
The other thing I would try for sure (since it works under XP) would be in the constructor of your CFileDialog would be to make sure to set bVistaStyle to FALSE. This ensures m_bVistaStyle is set to FALSE which it is set at when running under XP.
I have an MFC application that uses an ancient (circa 1999) third-party ActiveX control.
Since upgrading the project from VS2008 to VS2010, I'm having problems...
In the OnSize handler of the parent dialog IsWindow always returns false for the handle returned by control.GetSafeHwnd(), even when GetSafeHwnd() returns a non-NULL value. The rest of the control's parent dialog is displayed fine, but it doesn't seem to respond to any input.
I've seen this article, but GetSafeHwnd() isn't returning NULL in this case (after the first time that it is called, which is before the control is instantiated).
The control does cause the trace message "Control wants to be windowless" to be output when it's loaded. However it also does this when compiled in VS2008, so this may be a red herring. Searching for this message points me to creating a class derived from COleControlSite, and denying the control windowless-ness, but it seems there are no good example of this available, and as I say, it's not clear that this is really the cause of the problem.
I've also found this issue mentioned on MSDN's VS2010 porting page:
"An ActiveX control compiled by using Visual C++ 6.0, when embedded in
a dialog box in a project developed by using Visual C++ 2010, may
cause your program to assert at run time. In this situation, open the
ATL or MFC project associated with the ActiveX control in Visual C++
2010, and recompile it.. The assert will be in the file occcont.cpp,
on this line in source: ASSERT(IsWindow(pTemp->m_hWnd))."
I assume that there's something about VS6-compiled ActiveX controls that causes the window handles to be treated as invalid by the current Win32 implementation of IsWindow. The suggested solution is of course unhelpful as it's a third-party control, and we can't recompile it.
Has anyone managed to get around this?
I've already found solutions for VS2010 projects not running on Windows 2000, and errors linking to ODBC, but don't seem to be able to find anything on this one.
Thanks,
Chris
I didn't find a solution to this in the end - upgraded the controls to a VS2010-compatible version.
For what it's worth: if you don't care whether the control will appear transparent or not, you may force the control to have a window anyway - even though it can operate without a window.
You see, the ActiveX control must first ask the container (the window which will host the control) if it's okay to be activated without a window. This is simply because not all containers support windowless activation.
If this interface (IOleInPlaceSiteWindowless) returns okay then it proceeds with this special windowless activation, if not a window will be created for the control as normal.
Disclaimer:
I don't know if this 'unnecessary' window will make the assertion failure go away. In other words: I don't know if the window handle is passed down 'deep' enough into the AX control.
More about the IOleInPlaceSiteWindowless interface:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms682300(v=vs.85).aspx
I'd like to humbly ask: How can I debug a wince executable(.exe) that has been stored on the wince device, using Visual Studio's debugging facility.
As we all know, using VS2005, we can create a Win32 Smart Device Project(.vcproj)，add our source files to it, compile, select a target device, and press F5, then the generated exe will be deployed to the wince device and gets attached to the VS2005 wince debugger. But I'd really like to know, if someone has a wince exe(call it stock) already in his wince-device and have source code corresponding to that exe, HOW DO I start debugging that stock exe directly WITHOUT compiling the source code? I cannot compile the source code perhaps because I'm missing some library source or other reason.
For PC program, I know I can open an exe as a project so to start debugging that exe. I can find the main() function and set a break point on its first statement, then F5 will stop at that break point.
Thank you in advance.
I often run into this problem as well; I wish the "exe project" created would allow changing the debugger to "Smart Device Native Debugger" (or somehow set the platform) -> Let me know if someone knows how to do that.
The two ways I have been able to work around this are:
New Project Method:
Create an empty "Smart Device" project with no source code.
Change the "Configuration Properties > Debugging > Remote Executable" to your "Stock EXE" that you put on the device, ie: \FlashDisk\MyApp.exe
F5 to debug, and choose "Yes" when it says "deployment errors, do you wish to continue".
Attach to Process Method:
Same as above, but, instead of editing "Remote Executable" just start the "Stock EXE" via rapistart.exe / running manually via screen. Then make sure the "Attach to Process" transport is set to "Smart Device" and you should be able to attach.
After this you need to manually load the pdb, choose src files, etc, as you would a normal PC app.
If you want to debug a .NET CF managed application then the following link should help:
http://msdn.microsoft.com/en-us/library/b1ksfbk7%28VS.80%29.aspx
I only used managed .NET CF but I found this link that has loads of goodies on how to debug both managed and native code on a Windows Mobile 5 in VS2005. Most of it should apply to Win CE as well:
http://msdn.microsoft.com/en-us/library/aa446524.aspx
I figure out the method lately after going through quite a lot of reading and experiment(so many tricky points that Microsoft does not clearly document). user2093823 kindly summarized the procedure.
Some historical screen shots: