Welcome, Guest.
Please login or register.
WinX versus WIN API combobox down-arrows
Forum Login
Login Name: Create a new account
Password:     Forgot password

XBLite Forum    General Boards    Files Area  ›  WinX versus WIN API combobox down-arrows
Users Browsing Forum
No Members and 1 Guests

WinX versus WIN API combobox down-arrows  This thread currently has 11,905 views. Print Print Thread
1 Pages 1 Recommend Thread
engineeral
March 23, 2011, 8:00pm Report to Moderator Report to Moderator
Baby Member
Posts: 5
I used WinX with ViXen to generate my program framework after I had trouble with the Windows API and ViXen.  But I notice that the "drop-down-arrow-button" (whatever you call it) in the right corner of a combobox is partially hidden using the WinX version, while the Windows API version has a nice clean-looking "drop-down-arrow-button"

You can see the difference in the two versions with the attached small graphics.

What tweek in the WinX version is partially hiding these button?  It doesn't look nice, or standard.

What might I do to make the WinX version of myprogram look more like the standard Windows API?

Thanks.

Al Taylor.



This post contains attachments; to download them you must login.

Logged Offline
Private Message Private message
Guy1954
March 23, 2011, 8:53pm Report to Moderator Report to Moderator

Medium Member
Posts: 187
Hi Al,

I believe you used the extended style $$WS_EX_CLIENTEDGE.
Could you confirm that its removal corrects the combobox's visual appearence?

Bye! Guy
Logged Offline
Site Site Private Message Private message Reply: 1 - 6
engineeral
March 25, 2011, 7:12pm Report to Moderator Report to Moderator
Baby Member
Posts: 5
I tried replacing $$WS_EX_CLIENTEDGE with $$WS_EX_STATICEDGE - no change in the appearance.  I tried instead $$WS_EX_WINDOWEDGE - also no change in appearance.

I looked at the source code for WinX.x  In WinX.x the $$WS_EX_CLIENTEDGE is used only once - in the function WinXAddEdit and I have no trouble with the appearance of edit boxes.

I looked at the WinX.x code for function WinXAddComboBox.  As the code came to me in \winx_0_6_0_13_sources_1125\WinX_0_6_0_13_sources which I downloaded from this forum not long ago I can compile WinX.x fine.  But if I change line 1023 from:
hCombo = CreateWindowExA (0, &$$WC_COMBOBOXEX, 0, style, 0, 0, 0, listHeight+22, parent, idCtr, hInst, 0)
to
  hCombo = CreateWindowA (&$$WC_COMBOBOX, 0, style, 0, 0, 0, listHeight+22, parent, idCtr, hInst, 0)  'note three changes
           ' change CreateWindowExA to CreateWindowA, change $$WC_COMBOBOXEX to $$WC_COMBOBOX
           ' and delete the original first argument - was a zero in CreateWindowExA - because that argument is not used in CreateWindowA

and try to compile I get this error:

> Executing: C:\xblite\bin\xblite.exe "C:\xblite\winx_0_6_0_13_sources_1125\WinX_0_6_0_13_sources\WinXC.x" -conoff -lib -m4
> Compiling as a function library (DLL).
> Calling m4 macro preprocessor.
C:\xblite\WINX_0~1\WINX_0~1\WinXC.x(1020): Kind Mismatch(27)
> Done. Compiled file in 1360 msec
***** ERRORS =  1 *****
> Execution finished.


This I can't understand because line 1020 is:
     'style = style|$$CBS_SIMPLE
a comment line.  The 28th character position is the "L" in SIMPLE.  

However, the 28th character position in line 1023 (the line with the call to function CreateWindowA) is the "&" character in the function argument.

Huh??  WC_COMBOBOX and WC_COMBOBOXEX are both window classes (http://msdn.microsoft.com/en-us/library/bb775491%28v=vs.85%29.aspx)

Have I discovered two problems?  Or only one?  Or have I some other elementary programming error?

Alan Taylor.







     
     
Logged Offline
Private Message Private message Reply: 2 - 6
Guy1954
March 27, 2011, 7:39am Report to Moderator Report to Moderator

Medium Member
Posts: 187
Hi Al,

1. removal of $$WS_EX_CLIENTEDGE extended style mask
Proceed as follows:
- run viXen on your project
- "unselect" $$WS_EX_CLIENTEDGE with Ctrl+mouse Left-click
- save and generate

2. WinX's $$WC_COMBOBOXEX vs WinAPI's $$WC_COMBOBOX
As you noticed, WinX uses the EXTENDED combobox class. Callum did so because it covers all the possibilities of $$WC_COMBOBOX, with some additional "niceties". However, they don't have the same Windows event messages. If you change WinX's combobox class, you invalidate all the associated WinXComboBox_* functions. Basically, you shoot yourself in the foot! (outch!)

Bye! Guy
Logged Offline
Site Site Private Message Private message Reply: 3 - 6
engineeral
March 28, 2011, 2:30pm Report to Moderator Report to Moderator
Baby Member
Posts: 5
Thank you, Guy.  I'm glad you pointed out this feature of ViXen because I had missed it before.  When I did as you said I got better-looking comboboxes.

I am still having trouble with the compiler  - but that's for another thread, and once I can pin it down better.

Alan Taylor.

Quoted from Guy1954
Hi Al,

1. removal of $$WS_EX_CLIENTEDGE extended style mask
Proceed as follows:
- run viXen on your project
- "unselect" $$WS_EX_CLIENTEDGE with Ctrl+mouse Left-click
- save and generate

2. WinX's $$WC_COMBOBOXEX vs WinAPI's $$WC_COMBOBOX
As you noticed, WinX uses the EXTENDED combobox class. Callum did so because it covers all the possibilities of $$WC_COMBOBOX, with some additional "niceties". However, they don't have the same Windows event messages. If you change WinX's combobox class, you invalidate all the associated WinXComboBox_* functions. Basically, you shoot yourself in the foot! (outch!)

Bye! Guy


Logged Offline
Private Message Private message Reply: 4 - 6
engineeral
March 28, 2011, 6:21pm Report to Moderator Report to Moderator
Baby Member
Posts: 5
I think I have solved my immediate problem of getting extended comboboxes using WinX to look like regular comboboxes using the Windows API.  For me I took the XBLite code generated by ViXen using WinX and for the extended comboboxes I removed the $$WS_BORDER from the style of the extended combobox and changed $$WS_EX_CLIENTEDGE to $$WS_EX_WINDOWEDGE.

It looks like if you only change CLIENTEDGE to WINDOWEDGE you get some change but still have a heavy border.  Removing WS_BORDER lightens things up.  I guess WS_BORDER combines with WS_WINDOWEDGE to make an extra-thick border.

Alan Taylor.
Logged Offline
Private Message Private message Reply: 5 - 6
Guy1954
April 3, 2011, 2:36am Report to Moderator Report to Moderator

Medium Member
Posts: 187
Hi Al,

I investigated the bug you reported. For some reason, I did not figure out immediately what the problem was. I corrected viXen and you can download the corrected version at SourceForge. Thanks for your bug report; like they say: "A bug report means a use report". (Actually, I heard rather "No bug, no use!", but same difference!)

Happy vixening!
Bye! Guy
Logged Offline
Site Site Private Message Private message Reply: 6 - 6
1 Pages 1 Recommend Thread
Print Print Thread

XBLite Forum    General Boards    Files Area  ›  WinX versus WIN API combobox down-arrows

Thread Rating
There is currently no rating for this thread