Hi,

we want to discuss a bug report
http://bugs.freepascal.org/view.php?id=25554 here, not in Mantis (hope, I understand Bart right).

Today, the TPageControl.OnChange event behave different in Lazarus than in Delphi. In Delphi it is only called (so the bug report), if the user change the page. In Lazarus it is also called, when the page is changed by code.

I like (need) the behaviour in Lazarus, cause I mostly use blank TPageControls, with dynamic added pages and filled with dynamic created TFrames (created on demand). So for me it isn't important, if the user select a page or it is selected by code, I need the OnChange event to create or initialize the TFrame.

If I understand Bart right, he had a fix for that bug report, but than the behaviour now is gone.

I would prefer a option like nboCallPageChangeByCodeSelection to keep the current behaviour (so it doesn't break Lazarus code). A other possibility would be a new event like OnChangePage (as a replacement for the current Lazarus TPageControl.OnChange).
I wouldn't throw the current (in my eyes: better) behaviour away.

What is your opinion?

Kind regards

Michl

Isn't TTabSheet.OnShow enough for you?

Ondrej

Ondrej Pokorny wrote

Isn't TTabSheet.OnShow enough for you? Ondrej

Interesting approach!

I've just tested it in one of my apps and yes, it seems to work too. So this could be a obviously better solution for me.

Thank you for that hint!

Kind regards

Michl

Michael W. Vogel wrote

If I understand Bart right, he had a fix for that bug report,

Not yet ;-)

Bart

On 10/3/16, Michael W. Vogel via Lazarus wrote:

OT reply: I can't see you on contributors list?

Bart

Bart wrote

OT reply: I can't see you on contributors list? Bart

No, I'm sorry, I'm not a Lazarus developer.

Ah, OK. I inserted the solution from Ondrej in my current project and it really seems to be the better approach. If there is no other opinion to that topic, you can ignore my initial hint.

Now, there is only the gap of Lazarus and Delphi compatibility versus Lazarus consistency.
I don't know, how many other Lazarus user use the TPageControl.OnChange event in the same manner as I do. If no one else, there is no barrier to change it to Delphis behaviour ;)

Offtopic: Maybe is Delphis behaviour not really consistent. For example, TEdit.OnChange is fired, if the TEdit.Text is changed by user or code.

Kind regards

Michl

Michael W. Vogel wrote

Offtopic: Maybe is Delphis behaviour not really consistent. For example, TEdit.OnChange is fired, if the TEdit.Text is changed by user or code.

I agree, same inconsistency in Lazarus e.g. OnSelectionChanged for TRadioGroup is fired when ItemIndexis changed in code.

Bart

Could somebody add Michael to the contributor's list?

Michael W. Vogel wrote

Offtopic: Maybe is Delphis behaviour not really consistent. For example, TEdit.OnChange is fired, if the TEdit.Text is changed by user or code.

Maybe an additional property defining the behavior of the appropriate callbacks for all those controls to be "UserAction" "ProgramAction" or "Both", defaulting to the Delphi behavior might be a good idea.

-Michael

Thats sounds interesting!

A lot of newbies errors rest upon this, I often can see in the forums, e.g. endless loops:

TFooControl.OnChange (called by user) -> change TBarControl.Text TBarControl.OnChange (called by code) -> change TFooControl.Text TFooControl.OnChange (called by code) -> ...

Of cause, it would be a big job (for all widgetsets), to implement such a property (FOnChange is inserted on various class places), but IMHO it isn't impossible to do it for useful controls.

But I'm not sure, would such a property be accepted by the Lazarus developer?

Kind regards

Michl

Michael W. Vogel wrote

But I'm not sure, would such a property be accepted by the Lazarus developer?

I am against. LCL is designed to be Delphi-compatible so the default events are what they are and they behave how they behave.

Furthermore it would be quite hard to make it work on all WS because in a lot of cases you don't get the information from the WS what caused the change. A good example for a problematic component is TComboBox under Win32 (btw. TComboBox.OnClick isn't Delphi compatible either).

If you need an "event" when something changed programatically, call a method directly after the change.

(Well my opinion may change if you supply good arguments and supply a patch that makes the new "OnChangeEx(Sender: TObject; Reason: TChangeReason)" event work on all major WS for basic controls.) IMO the effort and maintenance don't pay off.

Ondrej

Ondrej Pokorny wrote

I am against. LCL is designed to be Delphi-compatible so the default events are what they are and they behave how they behave.

This of course is granted by a property that is not existing in Delphi and defaults to the Delphi behavior.

-Michael

Michael W. Vogel wrote

we want to discuss a bug report http://bugs.freepascal.org/view.php?id=25554 here, not in Mantis (hope, I understand Bart right).

I have remove the call to DoChange in r53089 and documented the changes in http://wiki.lazarus.freepascal.org/Lazarus_1.8.0_release_notes#TCustomTabControl_setting_TabIndex_or_PageIndex_by_code

@Michl: feel free to open a seperate bugreport for the feature request to make this behaviour configurable.
(Although I think you do not need it anymore?)

Bart

On 10 October 2016 at 10:12, Bart via Lazarus <

I think this is not logical. If the OnChange event is supposed to fire when the tab changes, and a PageIndex or a TabIndex changes the tab then it should do as it says. If the programmer wants Delphi compatibility then it is for the programmer to set a flag so that the OnChange event only fires when the end user changes the tab. In that case there should be a new event such as OnUserChange or something similar.

These illogical compatibility related definitions cause no end of trouble.If ill thought out definitions went into Delphi it is not smart to conform to them. Better make it known that they are illogical and that Lazarus and Freepascal do it the right way and gives them the option of switching to Delphi behaviour.

Delphi's developers faced exactly the same dilemma with respect to Windows' behavior. Some of the standard behavior triggering events did not make much sense and they had to decide to keep it as it was or define an improvement. For the most part they kept it as it was.

These are not easy decisions. One logical approach does not always work in all cases. However, good documentation alone goes a long, long way to improving the situation.

---- On Tue, 25 Oct 2016 14:43:09 -0400vfclists . via Lazarus &lt;&gt; wrote ----

On 10 October 2016 at 10:12, Bart via Lazarus &lt;&gt; wrote:

I think this is not logical. If the OnChange event is supposed to fire when the tab changes, and a PageIndex or a TabIndex changes the tab then it should do as it says. If the programmer wants Delphi compatibility then it is for the programmer to set a flag so that the OnChange event only fires when the end user changes the tab. In that case there should be a new event such as OnUserChange or something similar.

These illogical compatibility related definitions cause no end of trouble.If ill thought out definitions went into Delphi it is not smart to conform to them. Better make it known that they are illogical and that Lazarus and Freepascal do it the right way and gives them the option of switching to Delphi behaviour.

Unfortunately this will probably be impossible to make for all LCL-controls systematically. But we can make it for TPageControl - add a new option nboDelphiOnChange (or whatever) that defaults to Delphi OnChange behavior. If not set it will be the old OnChange behavior. Or they other way round: nboOldOnChange?

Or do you have any other name suggestions? I am pretty bad at this :) Such an option will make updating legacy code easier.
+ Bart: what do you think?

Ondrej

AFAICS Delphi does not have TPageControl.Options, so since this is already not Delphi compatible, I don't mind if we add such an option.

Others?

Bart

nboLazarusOnChange :)

+1

zeljko

Bart

I suppose it will not be a Boolean but the user can select (two) options with "speaking" names describing the technical effect ... -Michael

I don't want to make a separate property for this but create a new enum value for the Options property. IMO it shouldn't be a problem if it is documented.

Ondrej

+1 for new Options property instead of separate property.

zeljko

zeljko wrote

+1 for new Options property instead of separate property. zeljko

+1

Michl

Then there's the problem with what behavior should be default. If we say LCL is VCL compatible then it is clear, but the more I think about it the more I feel Delphi behavior is just strange. Probably thinking is not appropriate here...

The same problem is with TComboBox Style=csDropDownList. If ItemIndex is changed from code, OnChange is not fired. Now LCL is VCL compatible but it's the same case. Unfortunately TComboBox doesn't have an Options property.

Ondrej

Ondrej Pokorny wrote

Then there's the problem with what behavior should be default.

That supposedly can easily be defined by the general "mode" setting.

-Michael

Michael Schnell wrote

That supposedly can easily be defined by the general "mode" setting.

Mode switches are about coding (how the compiler should behave), not about how components should behave once compiled.

Bart

Ondrej Pokorny wrote

Then there's the problem with what behavior should be default. If we say LCL is VCL compatible then it is clear, but the more I think about it the more I feel Delphi behavior is just strange. Probably thinking is not appropriate here...

I agree, stop thinking ;-)
For the time being it miht be best to follow VCL behaviour...

Bart

Bart wrote

Mode switches are about coding (how the compiler should behave), not about how components should behave once compiled.

Of course I do know that they are used in that way. I just wanted to say that the Delphi compatibility modes *could* be used to define the *default* setting of this property. at compile time.

Seems rather logical to me.

-Michael

No, this is not technically possible. The mode settings have unit-scope. TPageControl/TCustomTabControl are in unit ComCtrls that is always built with objfpc mode.

Ondrej

Ondrej Pokorny wrote

The mode settings have unit-scope. TPageControl/TCustomTabControl are in unit ComCtrls that is always built with objfpc mode.

I see.

Thanks,
-Michael

If the existing functionality differs from Delphi, i say to keep the existing functionality as the default.

After all what is more important? Breaking existing Lazarus users' code or potentially having a Delphi code migration become slightly harder because a project will need to change a property (also isn't stuff like this why the IDE has options to import Delphi projects/units/forms/etc?).

On Wed, Nov 16, 2016 at 11:35 AM, Michael Schnell via Lazarus <

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20161116/6a033c18/attachment.html>