I built up a module that creates a window with an edit box from windows' EDIT windowclass. It is designed to only work with ansi character set and not using any unicode.
I make use of EM_GETHANDLE to recieve the buffer to the edit control.
Now here is my problem: (quoted from link above)
Note For Comctl32.dll version 6, the buffer always contains an array of WCHARs, regardless of whether an ANSI or Unicode function created the edit control. For more information on DLL versions, see Common Control Versions.
So when my module gets loaded by an application that has comctl32 initialized, my whole code breaks.
My Question: Is there a way to prevent CreateWindowA to use comclt32 or does anyone have an idea to fix this problem?
The application uses COMCTL32.DLL if it is specified in the app's manifest as described e.g. here: http://msdn.microsoft.com/en-us/library/windows/desktop/bb773175%28v=vs.85%29.aspx
If your module is DLL, then you might try use some isolation technique so it does not rely on what version of COMCTL32.DLL the .exe decided to use, but that might bring many other drawbacks.
I recommend to use WM_GETTEXTA or GetWindowTextA() instead, which will copy converted string into your buffer. Designing a module which requires old version of a DLL to work correctly is simply bad idea.
Related
I am designing a Windows Form app. I have an MDIParent form that loads in a maximized state, and loads its child forms in a maximized state as well. However, when I open an OpenFileDialog, or any datareader object, the MDIParent shrinks to a smaller size with all its forms and controls.
This solution Opening child form is causing mdiform to change size and shrink does not apply/work in my situation.
Also this solution https://support.microsoft.com/en-nz/help/967173/restoring-a-maximized-or-minimized-mdi-parent-form-causes-its-height-t did not work for me.
Some background: I have seen this behaviour in almost all my WinForm applications but I have never been keen to sort it out. I was able to narrow down to the causes as highlighted above when I started investigate it. Some posts are describing it as a windows bug, but it has existed for as long as the screen resolutions started going above 1024 (VS 2010) for my case. I hoped it is not just a windows bug...
I hoped it is not just a windows bug...
Feature, not a bug, but it is not one that Winforms programmers like very much. Notable is that there have been several questions about mystifying window shrinkage in the past few months. I think it is associated with the release of Win10 Fall Creators edition. It has deep changes to the legacy Win32 api layer and they've caused plenty of upheaval.
In your specific case, the "feature" is enabled by a shell extension. They get injected into your process when you use OpenFileDialog. The one that does this is very, very evil and does something that a shell extension must absolutely never do. It calls SetProcessDPIAware(). Notable is that it might have been written in WPF, it has a very sneaky backdoor to declare itself dpiAware. Just loading the PresentationCore assembly is enough. But not otherwise limited to WPF code, any code can do this and that might have been undetected for a long time.
One way to chase down this evil extension is by using SysInternals' AutoRuns utility. It lets you selectively disable extensions. But there is also a programmer's way, you can debug this in VS.
Use Project > Properties > Debug tab > tick the "Enable native code debugging" checkbox. Named slightly different in old VS versions btw. Then Debug > New Breakpoint > Function Breakpoint. Function name = user32!SetProcessDPIAware, Language = C. You can exercise this in a do-nothing WPF app to ensure that everything is set correctly. For completeness you can also add the breakpoint for SetProcessDPIAwareness, the new flavor.
Press F5 to start debugging and trigger the OpenFileDialog.ShowDialog() call. The breakpoint should now hit, use Debug > Windows > Call Stack to look at the stack trace. You typically will not see anything very recognizable in your case since the evil code lives in a DLL that you don't have a PDB for. But the DLL name and location (visible in Debug > Windows > Modules) ought to be helpful to identify the person you need to file a bug with. Uninstall it if you can live without it.
Last but not least, it is getting pretty important to start creating Winforms apps that are dpiAware so such a bug can never byte. You kick this off by declaring your app to be dpiAware so DPI virtualization is disabled. Plus whatever you need to do in your code to ensure the UI design scales properly.
I'm trying to handle all of User Interfaces (UI) dialogs in .msi installing pakage, with EmbeddedUIHandler to do this I have created a setupui.dll which contains three methods: InitializeEmbeddedUI, ShutdownEmbeddedUI, EmbeddedUIHandler, and put it inside of MsiEmbeddedUI table (using installshield) and it worked just fine.
The problem is when setupui.dll is dependent to other external DLLs, this time windows installer won't use my dll and it uses default ui, I have added other DLL dependencies with Installshield as follow:
I'm uncertain of what Windows Installer allows here. There are, however, three things that jump out at me as things to look into:
The MsiEmbeddedUI table's Attributes column should probably have a 3 for SetupUI.dll (as it does), and 0 for the rest. Per the docs, the 2 bit is ignored if the 1 bit isn't present, but all the other files are better described as "It may be a resource used by the user interface."
The verbose log: does it indicate what's going on? Does it show a failure loading SetupUI.dll that provides a useful error code (hint: file not found probably refers to a dependency)? Does it indicate it didn't even try to load your DLL? Look for lines with EEUI, at least in the successful case.
If Windows Installer does attempt to load SetupUI.dll, how far does it get? If it gets far enough for you to run some code and, say, show a message box, what files are already extracted at that point? If the dependencies are extracted, can you ensure that its directory is on the DLL path via SetDllDirectory or AddDllDirectory? If the dependencies are not extracted, are they present at a later point so approches like delay loading could help?
For the third point, Process Monitor may help you diagnose what's going on if you can't get a message box in there, but it will probably be less clear. Alternately, using Loader Snaps and Debug View might get you a related set of information, but it may be drowned in additional noise.
I’m working with an application for both Windows desktop and Windows store, potentially I will add Windows Phone in the future. I’m having most of my logic in a library and create different GUI for the different platforms.
I want to localize my application and want to share string resources between the platforms. But how do I do that?
For Windows desktop the most common approach seems to be using resx files. Here is a short example:
http://compositeextensions.codeplex.com/discussions/52910
For Windows store app resw files are used instead, here is an example of that:
http://msdn.microsoft.com/en-us/library/windows/apps/hh965326.aspx
Both these solutions are platform specific which I don’t like :-(. I really want to have all my string in one file/language and being able to use that in all platforms. Is there any solution for this?
Update 17 Feb 2014: As I understand it resx and resw files are in the same format. What is missing in Windows store app is that no class file is generated for the resw file. If I just could get a file like that my problems would be solved. Then I could put an instance of that class in my view model and access all text via properties.
The class file generated in WPF application almost works. The problem is this line that looks something like this:
global::System.Resources.ResourceManager temp = new global::System.Resources.ResourceManager("ResxTest.Properties.StringTest", typeof(StringTest).Assembly);
To get this to compile I need to change it to this:
global::System.Resources.ResourceManager temp = new System.Resources.ResourceManager("ResxTest.Properties.StringTest", typeof(StringTest).GetTypeInfo().Assembly);
But the resource ResxTest.Properties.StringTest can’t be loaded in my Windows Store application. For some reason I need to rename my resource to Resource.resw and load it with the name “Resource”. I have tried all kind of names but this is the only one that works. Using name MyApplication.MyResource never works.
I’m not sure if I’m on the right track. I’m almost so desperate that I will make my own solution were I convert an XML-file with all strings I needed to a huge class with properties that I could use to get all string without any resource files. But I think that is ugly and cheating so I hope someone could give me a better idea :-).
Update 24 Feb 2014: I was wrong! Things are working quite nicely with Portable class library. If I use that I could put an instance of auto generated C# class in my view model and access all strings from that object.
But if I use an ordinary library things doesn’t work as properly in Windows Store app (WPF is fine). I have tried to copy all files to a Windows store class library from a working Portable class library. When I try to create an instance of the auto generated file I always get:
An exception of type 'System.Resources.MissingManifestResourceException' occurred in mscorlib.dll but was not handled in user code
Additional information: Unable to load resources for resource file "MetroLib.StringResources" in package…
Quite annoying since I’m using the express editions of Visual Studio where portable class library isn’t available. So probably I will develop my own solution to generate classes from a resource file (which also gives me some other benefits). But I’m still curious what I’m doing wrong.
I finally solved the problem. I simply developed a simple tool (ResToCode) to convert resource files to pure C# classes. Quite similar to what Visual Studios resgen.exe is doing, but with some extra features. It works really well so I’m quite happy about it :-).
The tool is available for anyone at CodeProject:
http://www.codeproject.com/Articles/744528/ResToCode-Localization-tool-for-Windows-Desktop-St
You can put all your resources in a Portable class library and use these libraries on all platform. You might have to check what version of .NET framework you are using. Portable libraries are not available on all the versions of all the platforms.
http://msdn.microsoft.com/en-us/library/vstudio/hh871422(v=vs.110).aspx
http://msdn.microsoft.com/en-us/library/vstudio/gg597391(v=vs.110).aspx#members
Have you looked at the Multilingual App Toolkit? It keeps the translations in an industry standard XLIFF format and can generate resources files for Windows and Windows Phone.
I had the same issue with the MissingManifestResourceException for Portable Class Libraries too. Today I created a new Portable Class Library with another name (without the string 'Resources' in it): and it works like a charm. No idea why this hasn't worked before (perhaps the name of the resource).
[the following is a rephrase of my previous question, which was deemed ambiguous].
I'm digging into creating a basic licensing mechanism for a demo application. What I have in mind goes like that: the application creates an empty "license file" called, say "0b1xa487x.ini" upon the first run, then expires 30 days after it has been first executed and can't be run anymore as long as that specific file is present on the system.
What I'm looking for is a method to protect that specific file in a way to deter deletion. Since it will be a blank file, devoid of any content, I wouldn't mind it to be corrupt, have corrupt headers, invalid date, whatever it takes to stay undeletable.
I've seen a similar approach somewhere based on file attributes (the file had the HX attributes set in place); however, the attribute approach lead me nowhere, as I can't find any documented feature on the existence of a file attribute X.
I also know that there are other approaches including rootkit drivers and system services launched as system user, but this particular one seems to fit best in this scenario. Again, I outline that the file's contents may as well be inaccessible, I'm not planning to use the approach in running any kind of malware from the file, as I've been accused below :)
Corrupt suggests not conforming to some standard. There are no standards for blank files.
Thanks everybody for your suggestions. I found a way to render my file inaccessible, namely by using fortunate combination of file permissions. The downside is that these things don't work on non-NTFS partitions. The good thing is that I can always clean up after my application by simply removing these permissions programatically and deleting everything afterwards.
Regarding your last answer to Henk, I believe it is more easier to create a service, start it automatically with the OS, and open the file in the fmShareExclusive by using a TFileStream.
But, you can not force the kernel of the OS, or an antivirus to make your file 'undeletable'.
Best regards,
Radu
I have an application that uses LoadLibrary on Windows to dynamically load plugins. However some of the plugins have other dependent DLLs, such as database client DLLs.
When you attempt to load such a DLL and one of the dependent DLLs doesn't exist you get a nasty Windows dialog:
"The program can't start because xxx.ddl is missing from your computer. Try reinstalling the program to fix this problem."
Is there any easy way to avoid this dialog? I was hoping one could use LoadLibraryEx and pass a flag that says "don't give me that annoying dialog", but it doesn't seem like it.
What I'd like is for the application to handle that error, rather than Windows handling it for me, especially as the text of the message is incorrect (the problem isn't that the program can't start, the program is running quite happily, it just can't load this plugin).
What I'd like to avoid is having to rewrite the plugins that have these external dependencies to make them themselves do a dynamic load of any dependent modules and then query for any entry points.
Anyway, any suggestions would be gratefully received.
Use SetErrorMode(). Use it with SEM_NOOPENFILEERRORBOX | SEM_FAILCRITICALERRORS before you load the DLL and with 0 right after.
From MSDN:
To enable or disable error messages displayed by the loader during DLL loads, use the SetErrorMode function.
Link here