ICONICO

Discussion Thread

UniToolbox

Message Thread

Developer ComponentFor WindowsUniToolbox

UniToolbox iconThe leading control suite for Unicode development in Visual Basic.

Posted in the UniToolbox Forum.




UniCombo: another misbehaviour in Change event

Hello,

I just learned one unpleasant thing about UniCombo. When users picks an item with his mouse, two events are fired: Change and Click.
In standard Windows combobox, the Change event is only fired when users changes something in combo text, but not when an item is picked. In latter case, only Click event is fired.

This behavior of UniCombo is very unpleasant for me, because I'm in the middle of converting of big project with lots of combos and lots of tricky code in Change and Click events. This code assumes that Change is only fired when user changes content of combo manually. So this code does not work with UniCombo and needs to be rewritten. Needless to say, rewriting would not be necessary if UniCombo was compatible with standard windows combo.

Is there a way to make the UniCombo behave like standard combo and not fire Change event unless users changes the text?
by Wapper on Jun 7 2009 9:52am Reply

UniCombo: another misbehaviour in Change event

Thanks for posting, we can confirm that this is a difference in the controls. The UniToolbox controls were written from the ground up so unfortunately there will always be small inconsistencies between the standard controls. We hope the the conversion process is not too much of an ordeal for you.
by Nico Westerdale on Jun 7 2009 10:49pm Reply

UniCombo: another misbehaviour in Change event

Hi Nico,

It depends if you would call rewriting about 1000 event handlers an ordeal or not. I would call it disaster if you ask me. With all respect (and I have a lot of respect to Unitoolbox - it's an excellent product after all), this time I would really want to see a solution, not the standard reply about small inconsistencies. After all, Unitoolbox is supposed to be a drop-in replacement for standard controls. So if there are any incompatibilities or bugs, I would expect them to be fixed. Will it happen, or the Unitoolbox is frozen read-only and is sold basically without support? But the source code is still there, isn't it? Then it would probably only take an hour or less to fix things like this. Geesh, I would even agree to pay for fixing 1 bug and 1 incompatibility found in Unicombo.

Please don't say you're sorry to hear about all this.
Tell me and others that there will be fixes.

Regards,
Denis
by Wapper on Jun 8 2009 10:47am Reply

UniCombo: another misbehaviour in Change event

Denis,

I've discussed this with the developer and yes there is a difference in the behavior. Our thinking on why this is the case is as follows:

The UniCombo's Change event is fired when the text displayed in the text box part of the control _changes_. This text can be changed via keyboard input, or by selecting an item in the dropdown list, or programmatically using the UniCombo.Text property. If any of these three actions does not indeed change the existing text to something different then the Change event is not fired. For example, if a user selects the same entry in the dropdown list twice then the Change event will only be fired first time. This all seems quite logical to us, and is, in our opinion, the way the MS Combo should have been written. Obviously this is different to the way that the MS control is written.
by Nico Westerdale on Jun 12 2009 11:47am Reply

UniCombo: another misbehaviour in Change event

Nico,

Everything you wrote makes sense. But let me tell you why, in my opinion, did Microsoft design the Change event like this. The Microsofts' approach allows you to know when the content of the combo was changed by user and the combo is in "unselected" state - this may require some action ie. disabling "Save" button etc. With your approach, it is very difficult to do the same. Getting Change event may mean anything - was it manual change or a new combo row was selected, you don't know (of course you could try to trap manual changes with KeyDown event and some extra code, but the content can also be changed by mouse (Cut/Paste) and it is impossible to trap with MouseDown event). The worst thing, as I wrote in one of my previous posts, there is another inconsistency in Unicombo: if an item is selected and user changes text manually, then in Change event the combo is still positioned on the old row! This is very very close to bug and makes it even more difficult to trap manual changes and "unselected" state of the Unicombo.

Anyway, we could debate about different approaches and ways to write additional event code to handle simple situations like this, but my real point is, we should keep Unitoolbox as compatible to MS controls as possible, to make life easier for people like me who have been working with standard controls and need to convert existing projects. I don't think there're too many new systems written from scratch in VB6 these days, and .Net has full Unicode support. So the primary target should be existing VB6 systems, which in turn means that maximum compatibility should be kept with standard controls. Do you agree?

Can you please talk to the developer once more and let him read all this. And by the way, one more question: when a row is selected in Unicombo list, why in the world the Change event is fired *before* the Click event? I think the order should correspond to the logical process: first users clicks (Click event), then the data from the selected rows is copied to the Text property (Change event). One more thing that makes usage of Unicombo more difficult than is should be.

Regards,
Denis
by Wapper on Jun 14 2009 11:43am Reply

UniCombo: another misbehaviour in Change event

Denis,

Thanks again for your thoughtful and full post. You make some valid points, and yes we could go back and forth on them. The fact is that UniToolbox has been written with this behavior for many years now. If we do change this we are running the additional risk that previous clients will need to perform rework, so there is rework either way we cut it. For now we're going to go with what we have. Again apologies that this is not the easiest approach, but I think we'll have to keep our stand on this one.
by Nico Westerdale on Jun 15 2009 3:29pm Reply

UniCombo: another misbehaviour in Change event

Nico,

I understand and respect your concern about the approach taken long time ago. So, I have an idea. What if you could release another version of Unicombo (let's call it UniComboMS, UniComboA or something like this) with the event behavior as close as possible to the original Microsoft combo. You could make it a member of Unitoolbox typelib, or release it as separate ActiveX control. This would preserve the existing control and also help people who need to keep compatibility with MS. You could even sell the new version separately to people like me.

Please forgive my stubbornness, but I don't want to give up on Unicombo because so far it is the only Unitoolbox control with very serious incompatibility. And believe me, with current Unicombo version, it's a hell of a lot of work to rewrite existing event handlers to achieve acceptable compatibility.

Regards,
Denis
by Wapper on Jun 17 2009 12:24pm Reply

UniCombo: another misbehaviour in Change event

Denis,

Thanks for the suggestion, however at this point, especially as MS has withdrawn support for VB, we really don't think it would make economic sense to release a second component.
by Nico Westerdale on Jun 19 2009 10:49am Reply

UniCombo: another misbehaviour in Change event

Hi Nico,

Would you consider giving, or maybe selling the source code of Unicombo (please note I'm talking about Unicombo only) to me, so that we can arrange the necessary changes and compile the MS-compatible version? You could have the updated version back if you want.

Or can you otherwise help me? Please don't just say no. I'm your loyal customer and I'm in trouble. Too bad if the whole idea turns out to be a remarkable waste of time and money.

Denis
by Wapper on Jun 19 2009 11:06am Reply

UniCombo: another misbehaviour in Change event

Denis,

Yes we would be happy to sell you the source code for your own modification, and I do appreciate that you're in a tight spot! Please email me offlist at nico at iconico.com
by Nico Westerdale on Jun 19 2009 11:54am Reply

Our Software Stores

IconicoAccurate Design and Development Software

BitsDuJourDiscount Deal Coupons for Windows and Mac Software Apps

Our Software Services

IcoBlogOur Official Blog

© copyright 2004-2021 Iconico, Inc. Code & Design. All Rights Reserved. Terms & Conditions Privacy Policy Terms of Use Login