From: Robert M. <rob...@us...> - 2007-04-24 18:57:36
|
On 07/04/07, Glenn Linderman <pe...@ne...> wrote: > I turned on -dropdown => 1 for a Combobox, and got a -dropdownlist style > instead. > > The bottom two bits should be a 2-bit mask, for three values: simple = > 1, dropdown = 2, dropdownlist = 3. I'm not sure what 0 does... > looks/acts a lot like when simple = 1. OK, I can see what needs to be changed in the code. Can I confirm that you're changing the style of the dropdown at run-time? Will be fixed in the next release. [ As an aside a combobox treats no 'type style' the same as the 'simple' style. If you set the styles to 0 on creation, you should find that they are changed to 1 during creation]. Regards, Rob. |
From: Robert M. <rob...@us...> - 2007-04-24 19:38:21
|
On 24/04/07, Glenn Linderman <pe...@ne...> wrote: > On approximately 4/24/2007 11:57 AM, came the following characters from > the keyboard of Robert May: > > On 07/04/07, Glenn Linderman <pe...@ne...> wrote: > >> I turned on -dropdown => 1 for a Combobox, and got a -dropdownlist style > >> instead. > >> > >> The bottom two bits should be a 2-bit mask, for three values: simple = > >> 1, dropdown = 2, dropdownlist = 3. I'm not sure what 0 does... > >> looks/acts a lot like when simple = 1. > > > > OK, I can see what needs to be changed in the code. Can I confirm > > that you're changing the style of the dropdown at run-time? Will be > > fixed in the next release. > > Thanks, Rob, I'm not sure what you mean by changing the style of the > dropdown at run-time... I was using the -dropdown => 1 and > -dropdownlist => 1 sort of parameters to $mw->AddCombobox ... > > I wasn't doing anything like $cb->Change ... OK, so where you using more than one of -dropdown, -dropdownlist and -simple at the same time? I'm struggling to tie up what I think the code is dowing with what your describing. Rob. |
From: Robert M. <rob...@us...> - 2007-04-24 23:47:14
|
Glenn Linderman wrote: > I continued looking at this issue, and discovered some code in my "real" > program, that wasn't in the test program. > > Apparently, way back in the dark ages of Win32::GUI, in order to get > things to work right, I had to "fiddle" with some of the style > settings... and some of that code made its way into a common subroutine, > and got included in this program too. > > WS_VSCROLL | WS_VISIBLE | WS_CHILD | 1 > > The first two can be replaced in modern GUI by > > -vscroll => 1, -visible => 1 > > Not sure that the third one is really necessary now, I think it was > necessary then because it was -setstyle (later converted to -addstyle). -visible shouldn't be necessary. -vscroll is required if you want a vertical scrollbar on the comboxbox's listview window. Interesting history lesson. I think I am seeing the reason for -setstyle being marked deprecated, although I think it still has its uses if you know what you're doing. > Is there an option that is equivalent to WS_CHILD? No. Win32::GUI tries to get it right itself. You shouldn't need this today, unless you're trying to do something funky. > Not sure why the last one (1) was included, but clearly it is part of > the current confusion. The (1) is CBS_SIMPLE. So if you had this there and used -dropdown (CBS_DROPDOWN = 2) you'd actually get a dropdownlist (CBS_DROPDOWNLIST = 3 = CBS_SIMPLE | CBS_DROPDOWN). We're back to your original analysis. I'll fix it so that if multiple of these 3 options are used, only the last one will actually take effect, not a combination of them, and I'll fix the docs to indicate that they are mutually exclusive. Regards, Rob. |
From: Robert M. <rob...@us...> - 2007-04-25 01:18:56
|
Glenn Linderman wrote: > Speaking of history, I see I also have... > > -menu => 1 > > in the list of "standard options for listbox and combobox widgets". > Generally speaking -menu takes a menu handle/object parameter. But I'm > quite sure I used this option to make something work... any chance you'd > know what? I'll experiment with taking it out, but it'll make me > nervous until I retest all my old programs... I've not opened the source this time, but if I remember correctly the CreatWindowEx() API call overloads its HMENU parameter, because only a top level (main) window can have a menu. For a child window the field becomes a 'control id' - when working with windows resources this is the number that the programmer uses to refer to a child window, as window handles are only assigned at run time. In Win32::GUI we refer to everything by window name (-name), which we map internally to window handles, so the control ID (which I believe is what you're setting here) should be unnecessary. I've come across a couple of place where it matters not to have a control ID of zero, but, again, if I remember correctly this was related to custom-draw and owner-draw functionality. If you find anywhere else that it matter, then please let me know. > Thanks. For this and a few other multi-bit fields, I wonder if it is > really best to have > > -variation1 => 1, -variation2 => 1, -variation3 => 1 > > types of options, or if it would be better to have > > -variations => 1 > -variations => 2 > -variations => 3 > > Of course then one would rather have > > -combostyle => simple > -combostyle => dropdown > -combostyle => dropdownlist If I had a clean sheet to start from the last option you give would be my prefered option (although using strings rather than constants). > It would be simpler to document, and "mutual exclusion" would be easier > to explain... From the current starting point, yes. I have a few folder full of experiments that I have been doing, whilst wondering if a Win32::GUI V2, re-starting from scratch is the way to go. That was the approach I took. However, microsoft don't make it easy - it takes a lot of reading between the lines, experimenting and reeading of the header files to work out what's mulually exclusive and what's not! Regards, Rob. |