HMGforum.com

Hi All,

I've done a little research and found the following:

There are 17 controls in HMG having an 'OnChange' event.

Seven of these, don't fires the 'OnChange' event when its value is changed programmatically.

We have here a very clear case of 'collision' of two values that should be preserved: Library consistency and backwards compatibility.

As an (ex) Star Trek fan, while thinking about this I've recalled a Mr. Spock recurrent phrase:

"the good of the many outweighs the good of the few, or the one"

It's very clear for me that "the good of the many" here is to have a consistent, easy to learn and bug-free GUI library.

Making another decision could drive us to 'legalize' a bug simply because someone could created an application relying on it.

Doing that as a policy across time, will give as a library plenty of exceptions in controls behaviors, making it difficult to learn.

In such case, we should say to the users something like this:

"Onchange event, will fires when an interactive change occurs for all controls and when a programmatic change occurs only for some controls"

IMHO this is unacceptable.

We must be able to define 'OnChange' event like this:

"Onchange event, will fires when an interactive or programmatic change occurs for all controls"

Please, let me know what is your opinion about that.

Regards,

Roberto.

Roberto Lopez wrote:Hi All,
...
Please, let me know what is your opinion about that.

Hi Roberto,

I have a small suggestion: we can add a new command
SET PROGRAMMATICCHANGE ON | OFF
and guard the programmatic OnChange events in code by if condition.
When program will required an old behaviour then programmer may used a command
SET PROGRAMMATICCHANGE OFF
and by default it will be
SET PROGRAMMATICCHANGE ON

That's all.

Roberto Lopez wrote: Please, let me know what is your opinion about that.

My vote is for Mr. Spock His logic was always robust and consistent.

'Legalize' a bug, whatever reason is, certainly isn't befit to HMG.

I don't guess someone built a logic on "this control doesn't notice when ON CHANGE event fired by a programmatic intervention"

Only my humble opinion. I'm sure that Le Roy will decide the best, as always.

Best Regards

--

Esgici

IMHO there isn't a difference between programmatic and manual changes.

Change is change, whatever its source, must fire the appropriate event.

Regards

--

Esgici

It's very clear for me that "the good of the many" here is to have a consistent, easy to learn and bug-free GUI library.

Thank you Roberto. As of now, I call the 'on change event function/procedure' as and when I change the value programmatically.

IMHO, on change event shall be fired on both the occasions.

My doubt is, how come 10 controls have this property and 7 controls don't have? Is this windows bug?

gfilatov wrote:

Roberto Lopez wrote:Hi All,
...
Please, let me know what is your opinion about that.

Hi Roberto,

I have a small suggestion: we can add a new command
SET PROGRAMMATICCHANGE ON | OFF
and guard the programmatic OnChange events in code by if condition.
When program will required an old behaviour then programmer may used a command
SET PROGRAMMATICCHANGE OFF
and by default it will be
SET PROGRAMMATICCHANGE ON

That's all.

It's an interesting idea, but, IMHO, in the case that this command be implemented, it should work for all controls supporting 'OnChange' event, not only for the seven 'buggy' ones.

The reason for this, is the same that I've explained before (consistency across all controls).

Something that could help to keep backwards compatibility, will be check (for programmatic changes) that the new value be different from previous one, as a condition to execute 'OnChange' procedure. This should avoid the creation of endless loops in some situations (I've faced that myself when fixed checkbox/checkbutton OnCHange).

Regards,

Roberto.

esgici wrote: My vote is for Mr. Spock His logic was always robust and consistent.

Thanks in behalf of Mr Spock

Regards,

Roberto.

rathinagiri wrote:It's very clear for me that "the good of the many" here is to have a consistent, easy to learn and bug-free GUI library.

Thanks for your opinion.

rathinagiri wrote: My doubt is, how come 10 controls have this property and 7 controls don't have? Is this windows bug?

Not at all.

It's a lot more complicated and it's very difficult to explain on less than 20 pages

I'll try...

Win32 API is a lot much more different and complex than you can see in VB, VFP or MiniGUI library.

When I talked about that I've attempted to hide operating system complexities in MiniGUI, please... believe me... I've really done

From a Win32 API point of view, controls are handled in various different ways, usually according their 'age'.

Some controls are inherited from Win16 (Windows 3.x) epoch (yes... it's true ) some others where aggregated for Win32 (Windows 95/NT).

The concept of 'change' and 'value' are (in some cases) MiniGUI 'inventions' with no direct counterparts in WIn32..

This is the reason because MiniGUI is, by far, easier to use than other libraries, that only 'mimics' the Win32 behavior and structure.

A brief look to this (http://msdn.microsoft.com/en-us/library ... S.85).aspx) will give you an idea of the difficulties that implies to hide all that ******* things .

An example:

For WIn32 API, MiniGUI controls like button, checkbox, checkbutton, and radiogruop are all the same.

Yes, for Win32, all of these controls are buttons with different styles. Even worst, WIn32 buttons has no change event.

So, OnChange event for these controls are pure MiniGUI inventions.

The bottom line is: It's my fault and not a Win32 problem.

I hope I've clear enough (in less than 20 pages ).

Regards,

Roberto.

Ya. Crystal clear.

And I know now, how much efforts you had put forth to achieve simplicity. Hats off man. Bravo.

Now for the backward compatibility, IMHO, you can freeze this version and go for the next version, so that, the new version have cleared this.