ComboBoxGadget(): Full row selection ?

[Seldon]

@Seldon
I think a flag would be the easiest solution. Here I already made a feature request for this: http://www.purebasic.fr/english/viewtop ... =3&t=41921

Yes I agree and that flag could internally switch to old 'Combobox' class control.

[Mr Coder]

Agreed that an option to use the old style combobox is needed. I don't like the new version in 4.5 at all as it breaks my coloring callback and means I need to wrap all comboboxes with silly code to make it work like before. Bring back the old style please. Did anyone use images in comboboxes anyway?

[c4s]

Did anyone use images in comboboxes anyway?

C'mon that's unfair. It's clearly a good idea to add this possibility. But still for those of us who don't need it an optional flag should be available.

[Mr Coder]

It was a rhetorical question really. I don't ever recall seeing an image in a combobox in ANY app. Do you have an example that I can see, in a non-PureBasic app?

Also, maybe there's a way to create the old-style comboboxes with an API command, but then use the standard PureBasic commands with it to add content, clear it, etc? That would be okay.

[Demivec]

It was a rhetorical question really. I don't ever recall seeing an image in a combobox in ANY app. Do you have an example that I can see, in a non-PureBasic app?

Windows Explorer, Internet Explorer, File Open/Save/Print Dialogs, all using a combobox which can show icons.

[Trond]

It was a rhetorical question really. I don't ever recall seeing an image in a combobox in ANY app. Do you have an example that I can see, in a non-PureBasic app?

Windows Explorer, File Open/Save/Print Dialogs

Those can already be created with ExplorerComboGadget().

[freak]

I hear this with every update. "Why did you add this, nobody ever needs it". Then a while later the same people who complained in the beginning start using it as well.

Keep in mind that next time it may be the feature that is important to you that others find useless, so don't be too quick in making this argument.

[Trond]

The problem is with removing the existing functionality, not adding new.

[Seldon]

I never see any program or programming language which adds functionalities while removing older ones. The look of the new ComboboxGadget() is wrong (ok let's wait for the final release) and sincerely I don't want to change all my sources with the great srod's code. I think a compiler flag for the Windows version is needed. I think you only need to keep the older lib which opens the basic combobox class control and let the programmer choose.

[nco2k]

why dont you simply offer two gadgets?

Code: Select all

ComboBoxGadget(#Gadget, x, y, Width, Height [, Flags])
ComboBoxImageGadget(#Gadget, x, y, Width, Height, ImageID [, Flags])

problem solved.

c ya,
nco2k

[freak]

> I never see any program or programming language which adds functionalities while removing older ones.

We didn't remove any functionality. The differences are just cosmetic. The ComboBoxGadget() command still does what it always did in terms of functionality. The differences are a bug in the Windows common controls library and are only present on some Windows versions. If you want to complain, why not there?

> why dont you simply offer two gadgets?

Because having two gadgets that do exactly the same thing is just plain stupid.


The bottom line is that we probably will add a flag to decide between the old and the new behavior. I merely pointed out that neither "i won't use this feature anyway" nor "it breaks my API color hack" are valid arguments for that.

[Trond]

We didn't remove any functionality. The differences are just cosmetic. The ComboBoxGadget() command still does what it always did in terms of functionality.

Keyboard navigation is a pretty big feature and it doesn't work properly with the new combobox. Tabbing out of the combobox doesn't work. Selecting an item by typing its name doesn't work.

I merely pointed out that neither "i won't use this feature anyway" nor "it breaks my API color hack" are valid arguments for that.

I agree with that.

[nco2k]

> Because having two gadgets that do exactly the same thing is just plain stupid.

like ButtonGadget and ButtonImageGadget? ;P

well, it was just an idea and i dont see any problem with that.. after all, those are two different controls ComboBox <> ComboBoxEx.

c ya,
nco2k

[DoctorLove]

> Because having two gadgets that do exactly the same thing is just plain stupid.

like ButtonGadget and ButtonImageGadget? ;P

c ya,
nco2k

Wow, Clever One.

Anyway, Look at the delphi VCL set, There you have ColorCombo,ColumnCombo, MultiCombo..
So delphi is stupid too? I dont think its that hard to make it done with a flag, and even though keeping people source intact. Delphi already saw it coming with the Windows lib, they where ahead of the time.

[freak]

The example doesn't fit. ButtonGadget displays text, ButtonImageGadget displays an image. Neither of them can do the other. There is no overlap in functionality.

The combobox always displays text, with an _optional_ image. Use the imaginary ComboboxImageGadget, leave out the image and you are back at a regular combobox (plus some XP specific bugs, but that is not the point). Why have two commands to do the exact same thing? By your logic, there should be a separate TreeGadget and TreeImageGadget as well.

If you want to have tons of different ways to do the same thing, try Perl