1. Combo Box Odd Display Behavior
- Posted by wynco Nov 12, 2011
- 2100 views
I'm getting an odd display behavior in my combo boxes since switching to EU4. If the drop down list has more than 30 items then the empty space to right of the list's items has a black background instead white. As I mouse over the list the black disapears as the pointer moves over each item. Also any movement of the right scroll bar clears all the black. I'm using w32lib v0.70.18 and Vista Home Premium SP2.
Below is a sample program the demonstrates the effect on my system.
include Win32lib.ew constant MainWindow = createEx(Window, "Combo Box Bug Test", 0, 100, 100, 440, 100, 0, 0) constant ComboOne = createEx(Combo, "", MainWindow, 8, 10, 200, 0, 0, 0) for x = 1 to 30 do addItem(ComboOne, "Combo One") end for setIndex(ComboOne, 1) constant ComboTwo = createEx(Combo, "", MainWindow, 220, 10, 200, 0, 0, 0) for x = 1 to 31 do addItem(ComboTwo, "Combo Two") end for setIndex(ComboTwo, 1) WinMain(MainWindow,Normal)
2. Re: Combo Box Odd Display Behavior
- Posted by BRyan Nov 13, 2011
- 2048 views
I'm getting an odd display behavior in my combo boxes since switching to EU4. If the drop down list has more than 30 items then the empty space to right of the list's items has a black background instead white. As I mouse over the list the black disapears as the pointer moves over each item. Also any movement of the right scroll bar clears all the black. I'm using w32lib v0.70.18 and Vista Home Premium SP2.
Below is a sample program the demonstrates the effect on my system.
include Win32lib.ew constant MainWindow = createEx(Window, "Combo Box Bug Test", 0, 100, 100, 440, 100, 0, 0) constant ComboOne = createEx(Combo, "", MainWindow, 8, 10, 200, 0, 0, 0) for x = 1 to 30 do addItem(ComboOne, "Combo One") end for setIndex(ComboOne, 1) constant ComboTwo = createEx(Combo, "", MainWindow, 220, 10, 200, 0, 0, 0) for x = 1 to 31 do addItem(ComboTwo, "Combo Two") end for setIndex(ComboTwo, 1) WinMain(MainWindow,Normal)
I ran this code using my w32engin.ew .
The only difference is that my library just uses create instead of createEx
which does not use the last parameter (which is zero anyways )
include w32engin.ew constant MainWindow = create(Window, "Combo Box Bug Test", 0, 100, 100, 440, 100, 0) constant ComboOne = create(Combo, "", MainWindow, 8, 10, 200, 0, 0) for x = 1 to 30 do addItem(ComboOne, "Combo One") end for setIndex(ComboOne, 1) constant ComboTwo = create(Combo, "", MainWindow, 220, 10, 200, 0, 0) for x = 1 to 31 do addItem(ComboTwo, "Combo Two") end for setIndex(ComboTwo, 1) WinMain(MainWindow,Normal)
I ran this code on w32engin.ew using XP with no problem.
You can download my w32engin.ew from here if you want to test the code on vista.
http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan
Bernie
3. Re: Combo Box Odd Display Behavior
- Posted by DerekParnell (admin) Nov 13, 2011
- 2023 views
I'm getting an odd display behavior in my combo boxes since switching to EU4. ...
These is a known problem with Win32lib combos and tabs when using Vista or Windows 7. It has nothing to do with Eu4. It's on the list of repairs that I have to fix in the library.
4. Re: Combo Box Odd Display Behavior
- Posted by DerekParnell (admin) Nov 13, 2011
- 1984 views
It's on the list of repairs that I have to fix in the library ...
It looks like I might have already fixed this. Can you download the current release of the win32lib library and try this again. I've changed your sample program a little to help you with this...
include Win32lib.ew sequence title title = sprintf("Combo Box Bug Test v%d.%d.%d %s", Win32LibVersion) constant MainWindow = createEx(Window, title , 0, 100, 100, 440, 100, 0, 0) constant ComboOne = createEx(Combo, "", MainWindow, 8, 10, 200, 0, 0, 0) for x = 1 to 30 do addItem(ComboOne, sprintf("Combo One %2d", x)) end for setIndex(ComboOne, 1) constant ComboTwo = createEx(Combo, "", MainWindow, 220, 10, 200, 0, 0, 0) for x = 1 to 31 do addItem(ComboTwo, sprintf("Combo Two %2d", x)) end for setIndex(ComboTwo, 1) WinMain(MainWindow,Normal)
5. Re: Combo Box Odd Display Behavior
- Posted by wynco Nov 13, 2011
- 1974 views
I ran the changes you suggested and found I am actually using win32lib v0.70.20 13-Nov-2010. I cannot find a newer version. When I try to download the latest version the file I find has the same version number and date.
6. Re: Combo Box Odd Display Behavior
- Posted by DerekParnell (admin) Nov 14, 2011
- 1922 views
I ran the changes you suggested and found I am actually using win32lib v0.70.20 13-Nov-2010. I cannot find a newer version. When I try to download the latest version the file I find has the same version number and date.
That is unfortunate. I am running it here using Eu4, Windows 7 and winlib 0.70.20 and I am not seeing the effect you describe. I do remember this being an issue though, so maybe its just related to Vista?
Can someone else please try to confirm the issue?
7. Re: Combo Box Odd Display Behavior
- Posted by mattlewis (admin) Nov 14, 2011
- 1872 views
I ran the changes you suggested and found I am actually using win32lib v0.70.20 13-Nov-2010. I cannot find a newer version. When I try to download the latest version the file I find has the same version number and date.
That is unfortunate. I am running it here using Eu4, Windows 7 and winlib 0.70.20 and I am not seeing the effect you describe. I do remember this being an issue though, so maybe its just related to Vista?
Can someone else please try to confirm the issue?
I'm seeing it on XP. I suspect this is related to the manifest issue. I'm running the head of svn, which reports "v0.70.20 13-Nov-2010" as its version. Here's what I see:
- Inside each combobox, below the text, there is a black line.
- When I open the drop downs:
- The left box (30 items) has a white background, as expected.
- The right box (31) items has a black background. It has more items than are displayed, and there is a scroll bar. When I scroll the list, the background goes back to white. If I open the drop down later, it is black again.
Derek, it may be a difference in how many items are required to scroll (or a difference with XP and 7).
Matt
8. Re: Combo Box Odd Display Behavior
- Posted by ChrisB (moderator) Nov 14, 2011
- 1897 views
Hi
I have reported this issue before too, see
http://openeuphoria.org/forum/114950.wc#114950
Its definately a euphoria / win32 lib / windows combination problem, as it doesn't appear using Arwen.
It does kind of stop me using win32 lib at the moment (especially where certain controls are required)
Chris
9. Re: Combo Box Odd Display Behavior
- Posted by DerekParnell (admin) Nov 14, 2011
- 1885 views
Its definately a euphoria / win32 lib / windows combination problem, as it doesn't appear using Arwen.
That's the issue I now have to face, because I do NOT have the problem, and I am using "a euphoria / win32 lib / windows combination". So how to I fix something that I can't see is broken? It works perfectly correct on my system. Why? I don't have a clue.
Can anyone point me in some direction for help?
10. Re: Combo Box Odd Display Behavior
- Posted by mattlewis (admin) Nov 14, 2011
- 1881 views
Its definately a euphoria / win32 lib / windows combination problem, as it doesn't appear using Arwen.
That's the issue I now have to face, because I do NOT have the problem, and I am using "a euphoria / win32 lib / windows combination". So how to I fix something that I can't see is broken? It works perfectly correct on my system. Why? I don't have a clue.
Can anyone point me in some direction for help?
I recall the problem only happening when we compiled in the manifest with the interpreter. Translated programs don't get this (which is probably a bug), and don't display this unusual behavior.
I did a little testing (again, on XP), and we seem to be using the correct version of comctl32.dll (down in the winsxs x86 directory). Since other windows libraries (Arwen, wxEuphoria, w32engine) don't appear to have this issue, my best guess is that Win32Lib is somehow not initializing common controls correctly. I suppose the most obvious thing is to compare how the libraries do this differently.
Matt
11. Re: Combo Box Odd Display Behavior
- Posted by mattlewis (admin) Nov 14, 2011
- 1930 views
I did a little testing (again, on XP), and we seem to be using the correct version of comctl32.dll (down in the winsxs x86 directory). Since other windows libraries (Arwen, wxEuphoria, w32engine) don't appear to have this issue, my best guess is that Win32Lib is somehow not initializing common controls correctly. I suppose the most obvious thing is to compare how the libraries do this differently.
Since the problem is with backgrounds, it may have to do with something like a WM_ERASEBACKGROUND message. Or maybe something to do with Custom Drawing messages?
Matt
12. Re: Combo Box Odd Display Behavior
- Posted by ChrisB (moderator) Nov 14, 2011
- 1833 views
Its definately a euphoria / win32 lib / windows combination problem, as it doesn't appear using Arwen.
That's the issue I now have to face, because I do NOT have the problem, and I am using "a euphoria / win32 lib / windows combination". So how to I fix something that I can't see is broken? It works perfectly correct on my system. Why? I don't have a clue.
Ah, the beauty of computers. I don't either, and you are a far better man than me (at Euphoria)
Can anyone point me in some direction for help?
Take head to wall, bang repeatedly, always works for me.
Chris
13. Re: Combo Box Odd Display Behavior
- Posted by m_sabal Jun 22, 2012
- 1614 views
Yes this is an old thread, but it is still a current issue. I've spent way too much time trying to hunt it down, and have to call it quits for now and either move back to Euphoria 3/Win32 0.6 or jump to Java (eww). Here's what I know:
- In Vista and beyond, Microsoft changed the way ListBox, DropDownList, and ComboBox(Ex) were handled.
- The upgrade to Win32 0.7 took care of making the controls work correctly in the newer operating systems.
- At the same time, Win32 0.7 was written to allow it to work with Euphoria 4.
- In fDoColor, any control that wasn't directly created by Win32Lib gets no treatment.
- The dropdown portion of the control has a different Windows handle than the edit portion, so when a setBackground is issued on the combo, only the edit portion is affected.
Possible fixes:
- Declare Windows XP/2003 as unsupported with Win32 0.7. (Have to go back to Eu 3 + Win32 0.6, or use a different GUI toolkit.)
- Change the way ComboBoxes are styled in CreateEx, so that they are not user drawn. This removes the ability to add colors, images, and fonts.
- Find a way to get the parent of the wParam since wParam will have no reference in the sequences managed by win32lib, check if the parent is a dropdownlist or combobox, and apply the parent's font/color/background to the dropdown portion.
At this point I'm out of time and am reverting to Eu3 since too many of my users and servers are still on WinXP/2003.
14. Re: Combo Box Odd Display Behavior
- Posted by andi49 Jun 25, 2012
- 1515 views
Yes this is an old thread, but it is still a current issue. I've spent way too much time trying to hunt it down, and have to call it quits for now and either move back to Euphoria 3/Win32 0.6 or jump to Java (eww). Here's what I know:
- In Vista and beyond, Microsoft changed the way ListBox, DropDownList, and ComboBox(Ex) were handled.
- The upgrade to Win32 0.7 took care of making the controls work correctly in the newer operating systems.
- At the same time, Win32 0.7 was written to allow it to work with Euphoria 4.
- In fDoColor, any control that wasn't directly created by Win32Lib gets no treatment.
- The dropdown portion of the control has a different Windows handle than the edit portion, so when a setBackground is issued on the combo, only the edit portion is affected.
Possible fixes:
- Declare Windows XP/2003 as unsupported with Win32 0.7. (Have to go back to Eu 3 + Win32 0.6, or use a different GUI toolkit.)
- Change the way ComboBoxes are styled in CreateEx, so that they are not user drawn. This removes the ability to add colors, images, and fonts.
- Find a way to get the parent of the wParam since wParam will have no reference in the sequences managed by win32lib, check if the parent is a dropdownlist or combobox, and apply the parent's font/color/background to the dropdown portion.
At this point I'm out of time and am reverting to Eu3 since too many of my users and servers are still on WinXP/2003.
Hallo
Maybe you should try a Eu4.0 Version without a Manifest (means without CommonControls Version 6.0) compiled in. I think this is worth a try, before going back to 3.1.
If you do not have the resources, creating this binaries. I will to this for you. Just drop a line.
Becouse i think this problems are not basicly in OpenEuphoria but in the CommonControls 6 and up.
Andreas
15. Re: Combo Box Odd Display Behavior
- Posted by mattlewis (admin) Jun 25, 2012
- 1457 views
Yes this is an old thread, but it is still a current issue. I've spent way too much time trying to hunt it down, and have to call it quits for now and either move back to Euphoria 3/Win32 0.6 or jump to Java (eww).
I posted one way to fix this issue here:
http://openeuphoria.org/forum/m/117380.wc
This was what I said:
The problem appears to be in win32lib.ew:fDoCtlColor(). It's there apparently to override the foreground and background color selections for controls. Apparently, the themed settings are slightly different than non-themed settings, at leaast on XP. To turn it off, you can simply modify the function so that it always does:
return {kMainMsg , -1}
If you've been taking advantage of the features of win32lib that use this, of course, they won't work any more (I'm not familiar with the motivation, etc, for this function, so I can't really say more). I found a modification that fixes the issue with the static labels by checking to see if win32lib believes the control should be transparent. Again, in fDoCtlColor, update the if statement that checks for w32WinDefColor to read:
if not equal( classBGColor[ctrl_Type[lControl]], w32BGTransparent ) and not equal(ctrl_Bg_Color[lControl], w32WinDefColor) then
That doesn't fix the combo's issues. I think the problem occurs with the Combo's edit box. Normally, those aren't transparent, so it doesn't get fixed by the transparency check, though the first suggestion, of making this function o NOOP fixes the combo box display.
For completeness, here is the simple example that demonstrates the issue:
include win32lib.ew constant Win1 = create(Window,"Strange",0,Default,Default,400,400,0), TabCtl = create(TabControl,"",Win1,5,5,380,355,0), Tab1 = create(TabItem,"First",TabCtl,0,0,0,0,0), Label1 = create(CText,"Nothing important",Tab1,10,30,360,25,0), Cbox1 = create(Combo,"",Tab1,20,80,250,100,0) WinMain(Win1,Normal)
Matt