I am a self taught hobbyist programmer of several decades. I am pretty darned good at googling and reading manuals to figure things out so it is rare that I feel the need to ask for help. I've only posted here once before. The docs are great. But as such, I do recognize I have large gaps in my knowledge.
I have encountered a problem with wxChoice.
I am building my program with CodeBlocks using the wxSmith plugin, on Windows, for Windows.
The behavior of the height of the pull down menu is inconsistent with the values I set and other build options, specifically on whether I've built my program to require admin rights or not.
This is a change in behavior from my previous wxWidgets version 3.0.4, which seemed to behave 'normally', or at least not in a way that attracted my attention as an issue.
Details about my build environment:
Windows 7 Home Prem x64
CodeBlocks 17.12 build Dec 25, 2017 08:45:27 - wx2.8.12 (Windows, unicode) - 32bit
wxWidgets 3.1.2 static built with the following arguments:
mingw32-make -f makefile.gcc SHARED=0 UNICODE=1 USE_OPENGL=1 BUILD=release
I am writing a program that uses low level direct physical disk access. This of course requires the program to have administrative rights under windows.
I am using a manifest file in my project's resource.rc file so the manifest is built into my final exe.
Although this is the first time I've used Admin Rights, I am pretty sure I am implementing my manifest and resource.rc files correctly based on google research and finding the same method suggested on numerous sites.
But just in case, here are my files.
My manifest file:
Code: Select all
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"> <assemblyIdentity version="184.108.40.206" processorArchitecture="X86" name="ChoiceStatic" type="win32"/> <description>Description of your application</description> <!-- Identify the application security requirements. --> <trustInfo xmlns="urn:schemas-microsoft-com:asm.v2"> <security> <requestedPrivileges> <requestedExecutionLevel level="requireAdministrator" uiAccess="false"/> </requestedPrivileges> </security> </trustInfo> </assembly>
My resource.rc file:
Code: Select all
aaaa ICON "wx/msw/std.ico" #include "wx/msw/wx.rc" 1 24 ChoiceStatic.manifest
Please see the attached image which is a composite of six different build scenarios described as follows:
To visually help, each program's title bar reflects the information below.
All scenarios have wxChoice menus populated with a list of 50 items. All code is identical in each build except for the height value assigned to the wxChoice and/or the requirement of admin rights to run. (and the title bar text)
The top row images all require admin rights, implemented as above.
The bottom row images are the same programs but with the manifest reference simply removed from the resource.rc file.
From left to right are samples of varying height values assigned to the wxChoice. From left to right in each row are -1 (ie use default), 20, and 30.
As you can see, under user rights, the height of the pull down is constant, but quite large, going to the edge of the screen.
Under admin rights, the height of the pulldown goes from nearly nothing with values -1 and 20 to a short list with value 30. At some value the behavior changes in a binary fashion. Below this value I get nothing, above I get a short menu. Testing has the behavior change between values 23/24.
I sometimes notice in my build log when doing Admin Rights builds the following line:
I do not know if this is related to the problem or not. Googling for this error has not found me any understanding of what it means. All I've gathered is that windres is what reads and compiles the resource.rc file.windres.exe: warning: 24: 1: 1033: duplicate value
My build finishes with a fatal error. But the code still runs fine other than the problem with wxChoice herein described.
I did not have this issue with my build until switching to a new CodeBlocks and wxWidgets version. I do not know with which change it is related as I did both at nearly the same time. But I suspect this is more likely a CodeBlocks issue.
I had originally started my project using a dynamic monolithic build of wxWidgets 3.0.4 and CodeBlocks 16.01. The height value I used for my wxChoice items was 21, as I understood that to be the default value. I thought this to be the height of the widget itself as that is the behavior for buttons and many other items. I was changing the width of the wxChoice hence why I was not just using the defaults to begin with.
As my program progressed, I lacked a feature which I needed, unrelated to this problem, that I discovered was available in 3.1.2, so I built a dynamic monolithic library. I did not notice any change in behavior as I also wanted to convert my program to use wxWidgets statically so I would not need a huge dll to go with my exe.
THAT is when I noticed the problem. At first I thought it was an issue with static builds. I went round and round trying to figure things out and being completely confused by my program's behavior as sometimes it worked, and sometimes not. I even tried building a reduced test case program but still had confounding behavior. It was not until I noticed a change in behavior based solely on admin vs plain user rights that the issue became clearer.
The behavior has nothing to do with monolithic vs static build. I tested that.
I wanted to test these scenarios out against 3.0.4 and possibly my older CodeBlocks 16.01 but unfortuntely by the time I had noticed the issue, I had already deleted these from my poor old laptop to save space. At best I might be able to try CodeBlocks 16.01 with wxWidgets 3.1.2 as I'd have to rebuild 3.0.4 from binaries. But that might not help as I can't guarantee I'd be building with the same arguments as I originally had with that version.
What exactly does the height value control? The height of the widget? Or the height of the pull down menu? Is it pixels? Or number of items listed? This doesn't seem to be documented.
Why does it behave differently between user vs admin rights?
It appears the value has no effect on user rights builds.
It appears the value has inconsistent behavior on Admin rights builds.
I thought I'd just go around the problem by trying to use another widget, specifically wxComboBox, but it also had similar behavior, although I did not test it as thoroughly as wxChoice.
Is my windres fatal error the key to the problem?
I am confident this is not a Windows issue as that is the one thing that has stayed the same while I develop my code.
If you've read this far, THANK YOU.