Hi,

Anybody here interested in joining the THelpEvent discussion in fpc-users mailing list...? Please post your comments there.

Regards,
- Graeme -

Hello Lazarus-List,

Thursday, November 5, 2009, 1:36:55 PM, you wrote:

GG> Anybody here interested in joining the THelpEvent discussion in GG> fpc-users mailing list...? Please post your comments there.

Where is that list ? I can only see, fpc-devel, other and pascal :-?

Graeme Geldenhuys wrote

Hi, Anybody here interested in joining the THelpEvent discussion in fpc-users mailing list...? Please post your comments there.

Sorry, a minor typo. That should have read 'fpc-pascal' mailing list.

fpc-pascal maillist -
http://lists.freepascal.org/mailman/listinfo/fpc-pascal List-Archive: http://lists.freepascal.org/lists/fpc-pascal

Regards,
- Graeme -

The fpc-pascal mailing list seems to quite for this discussion and Lazarus would have a greater impact on the suggested change, so I moved the conversation no Lazarus mailing list instead. Even though THelpEvent is defined in FPC (not Lazarus).

Yesterday I found that the THelpEvent definition in Kylix 3 is very different to the one in Delphi VCL. Looking at the code in FPC, it follows the Delphi implementation - even though the implementation is extremely outdated.

Here is the difference....

Kylix 3 type signature:
  THelpEvent = function(HelpType: THelpType; HelpContext: THelpContext;
       const HelpKeyword: String; const HelpFile: String;
       var Handled: Boolean): Boolean of object;
Free Pascal & Delphi type signature:
  THelpEvent = function (Command: Word; Data: Longint;
    var CallHelp: Boolean): Boolean of object;

I read the latest Embarcadero online help (available on the web) and it clearly mentions that the THelpEvent signature is based on the WinHelp help system and API.

Now considering that WinHelp is been discontinued by Microsoft and has been replaced twice already by different help systems... first CHM, then again with Microsoft Help 2 - it just shows how old and outdated WinHelp is.

My opinion is that FPC and Lazarus is not that closely tied to Windows and Windows API - well it shouldn't be, because both products are cross-platform tools and should have equal footing on all supported platforms.

The Kylix 3 signature seems more useful to me as a cross-platform developer, as it clearly defines the parameters (no ambiguous parameters) and sends all information needed to the OnHelp event handler. My proposal is that the THelpEvent definition in FPC be changed to the Kylix 3 signature.

Why - you ask?
* The K3 THelpEvent parameters are more related to newer help systems. Not tied to the deprecated WinHelp from Microsoft.
* The parameters used in that even is what is already defined and used elsewhere:
- HelpType (TComponent)
- HelpContext (TComponent)
- HelpKeyword (TComponent)
- HelpFile (TApplication)

So yes, this will break backward compatibility in Lazarus, but Lazarus is not the only GUI toolkit and development tools using FPC and it's classes. Also FPC and Lazarus have already implemented things that break compatibility with Delphi - simply because FPC and Lazarus are not so closely tied to Windows; it may be a better design and for the greater good (better cross-platform support).

Regards,
- Graeme -

Zitat von Graeme Geldenhuys :

Lazarus type signature:
   THelpEvent = function(Command: Word; Data: PtrInt;
       var CallHelp: Boolean): Boolean of object;

Where Data is PHelpInfo. It is used by the widgetsets.

I miss a "Sender: TObject".

I see no gain in Kylix compatibility.

Lazarus has already a help system, which is quite different from Delphi's.

Mattias

And which seems the same as FPC's THelpEvent, except for the type of the Data parameter. And any average Joe will know that Data means PHelpInfo??? I don't think so. Not even the RTL or LCL help mentions that - see links below.

I miss a "Sender: TObject".

Why, OnHelp only exists in TForm. No other class has a OnHelp event.

I see no gain in Kylix compatibility. Lazarus has already a help system, which is quite different from Delphi's.

It's not about Kylix compatibility either. It's about having more unambiguous parameter names and much clearer meaning of each parameter!

  Command: Word:    // No idea what that means or what are valid values
  Data: PntInt;     // No idea what that mean or what it points to
  var CallHelp      // No idea either?

Compare those parameter names to the following:

  HelpType: THelpType;
  HelpContext: THelpContext;
  HelpKeyword: String;
  HelpFile: String;

Any developer can figure out the second lot of parameters without the need to open a manual or online help document. Not to mention that neither Lazarus or FPC has help that explains the current meaning of the parameters in THelpEvent. Currently it's only a select few developers ( I guess) that know the meaning or those parameters. What still about the structure that Data points to?

http://lazarus-ccr.sourceforge.net/docs/lcl/forms/thelpevent.html http://www.freepascal.org/docs-html/rtl/classes/thelpevent.html

So considering that Application.HelpFile, TComponent.HelpContext, TComponent.HelpType and TComponent.HelpKeyword exists. How do you translate what comes currently though the OnHelp event handler to something like is it Context ID or a KeyWord etc?

As for the elusive PHelpInfo type (seeing that you mentioned what Data actualy contains). After browsing for quite some time I eventually seemed to find PHelpInfo. There is not link in the online help from OnHelp or THelpInfo to PHelpInfo by the way.

Anyway, this is what I found and I think it's ridiculously complicated. PHelpInfo is a pointer to THelpInfo which is a alias type to tagHelpInfo which is finally a record type with 6 fields. And out of those 6 fields not a single one uses the existing help types we have available: THelpType, THelpContext.

And you don't think that is more complicated to what I am suggesting?

Regards,
- Graeme -

Problem is that CHM can emulate .hlp basic topic retrieval, and that's probably why Delphi left it the same. I don't know what helptype K3 used.

But what I do not understand is why you need this identifier to change at all? Let it be there, all nice and Delphi compatible, and define your own for your own systems.

Marco van de Voort wrote

Problem is that CHM can emulate .hlp basic topic retrieval, and that's

And why must that problem become FPC's problem? FPC is meant for multiple platforms, not just Windows platform. So solutions should be based on what makes sense in a cross-platform way.

But what I do not understand is why you need this identifier to change at all? Let it be there, all nice and Delphi compatible, and define your own for your own systems.

As I said above. FPC is for multiple platforms, not just Windows. Many other features have changed in FPC for example that reason - even if that means breaking Delphi compatibility.

TComponent is part of FPC. So is THelpContent and THelpEvent, THelpType etc... So why reinvent the wheel (or declare yet more custom type), when we should be able to use what is available in FPC itself - and built on top of that. Irrespective of what GUI toolkit or platform we use.

This concept is implemented all over in FPC, THelpEvent is just another case that hasn't been attended to.

What makes my point in more appropriate is that Lazarus doesn't even use the THelpEvent as defined in Classes unit. They implemented there own type in the Forms.pp unit, so no, the change I suggest will not even break Lazarus code.

Regards,
- Graeme -

This is not the same. Other parts are changed when it is not possible otherwise. In other places, the default identifiers are reserved for Delphi compatibility, and 3rd party alternatives define their own.

What makes my point in more appropriate is that Lazarus doesn't even use the THelpEvent as defined in Classes unit. They implemented there own type in the Forms.pp unit, so no, the change I suggest will not even break Lazarus code.

I don't see anything appropriate there, and no need to change this at all

Marco van de Voort wrote

This is not the same. Other parts are changed when it is not possible otherwise. In other places, the default identifiers are reserved for Delphi compatibility, and 3rd party alternatives define their own.

....

I don't see anything appropriate there, and no need to change this at all

Lazarus is probably the only other "big" contender in being Delphi compatible. Remember that FPC is used by more that just Lazarus project. If the default THelpEvent type was that appropriate, then why did Lazarus of all projects, decided to redefine that type in the forms.pp unit?

Not even FPC or Lazaurs or MSEgui or fpGUI uses THelpEvent, so who are you actually keeping it "delphi compatible" for? Everybody that wants to use it, redeclares there own - so clearly there is a issue with the default declaration in FPC.

Regards,
- Graeme -

Yesterday I found that the THelpEvent definition in Kylix 3 is very different to the one in Delphi VCL. Looking at the code in FPC, it follows the Delphi implementation - even though the implementation is extremely outdated.

FPC imports more oddities from Delphi, like the new change of Inc() :-(

While I agree that FPC and Lazarus should be allowed to deviate from the Delphi VCL and RTL interfaces, I'd wait for Delphi "X" before changing anything, or for the death of Delphi, whatever happens earlier :-]

My opinion is that FPC and Lazarus is not that closely tied to Windows and Windows API - well it shouldn't be, because both products are cross-platform tools and should have equal footing on all supported platforms.

ACK.

Before doing so we should check the existing help systems, e.g. on MacOS, for compatibility. Then the related type declarations can be updated in the same step, if required.

I'm not sure about the HelpFile property - at least a default (Form?) helpfile should be usable, just for more convenience and better maintenance.

I'd like to break with the drag-dock model as well. It has turned out that it doesn't fit multi-platform requirements, and is not available in CLX at all!

DoDi

Hans-Peter Diettrich wrote

FPC imports more oddities from Delphi, like the new change of Inc()

That broke my code too, but if it fixes some odd cases or ambiguous code, I'm all for it. It was quick to fix my code anyway.

the Delphi VCL and RTL interfaces, I'd wait for Delphi "X" before changing anything, or for the death of Delphi, whatever happens

That's like saying FPC cannot evolve without Delphi. That should never be the case! FPC is a product on it's own - delphi compatibility should be a "nice to have". Look what happened to Borland when they trying to wait and see what .NET or Visual Studio does before they support those features. Always playing "catch-up" is a recipe for disaster and you will ALWAYS be second best.

Before doing so we should check the existing help systems, e.g. on MacOS, for compatibility. Then the related type declarations can be updated in the same step, if required.

The new parameters I proposed are not new types, they are simply information and types that already exist in TComponent or TApplication.

> So yes, this will break backward compatibility in Lazarus, but > Lazarus is not the only GUI toolkit and development tools using FPC

As I stated later.... After looking in more detail at Lazarus code, I saw they implemented there own type, so no, this change will not even break Lazarus code.

I really don't see the issue here - nobody seems to be using the declaration in the Classes unit! I would like to though in fpGUI, but not in its current state.

Regards,
- Graeme -

Why not just introduce a new type with a different name?

Maybe TCLXHelpEvent = function(HelpType: THelpType; HelpContext: THelpContext;
      const HelpKeyword: String; const HelpFile: String;
      var Handled: Boolean): Boolean of object;

This should stop the discussion about breaking compatibility and get it into FPC. It doesn't really need to be called THelpEvent to be useful, does it?

Inc() has not been changed but properties got a consistent behaviour.

Note that Delphi (version 7, at least) does not have THelpEvent declared in the classes unit. The question is, why does FPC have it there? To be compatible with Delphi, it must be removed. This applies not only to THelpEvent, but to some more declarations as well. I had to patch one of them away just yesterday (Mantis #14948).

Sergei

Felipe Monteiro de Carvalho wrote

Why not just introduce a new type with a different name?

Then what's the point of having THelpEvent then? Nobody currently uses it, but I would like to in fpGUI.

This should stop the discussion about breaking compatibility and get it into FPC.

Breaking compatibility with hows code? All source code I searched, doesn't use it. Lazarus was the first on my list, but it has it's own definition in forms.pp unit.

It doesn't really need to be called THelpEvent to be useful, does it?

Well, I'm trying to make the current THelpEvent useful and actually trying to use it in fpGUI. Currently I have my own type TfpgHelpEvent, but why invent a new type when I could have used the one in FPC.

I keep hearing "compatibility, compatibility, compatibility..." But to what and in how's code?
Borland was OK with changing the type for Kylix 3 because they clearly saw it is to specific to WinHelp, so made it more cross-platform friendly. So if such a change was OK for Borland, then why the resistance to have it changed in FPC - which is also designed to be cross-platform friendly?

Regards,
- Graeme -

Sergei Gorelkin wrote

Note that Delphi (version 7, at least) does not have THelpEvent declared in the classes unit. The question is, why does FPC have it there?

True, in Delphi it is declared in the Forms unit. That makes sense to them because TApplication is also in the Forms unit. And the only two classes that use OnHelp (THelpEvent) is TApplication and TCustomForm.

But in FPC, TCustomApplication is in it's own unit and not tied to a GUI toolkit. So in FPC I can understand why they did not define it in CustApp unit (not all apps descend from TCustomApplication) or Forms unit (because FPC doesn't have a GUI) but rather the Classes unit.

Regards,
- Graeme -

> FPC imports more oddities from Delphi, like the new change of Inc() That broke my code too, but if it fixes some odd cases or ambiguous code, I'm all for it. It was quick to fix my code anyway.

Breaking changes are not desireable at all, without an option to disable them. Delphi has already forked into incompatible Ansi and Unicode versions, which require to retain an Ansi compiler, IDE and RTL/VCL for the maintenance of legacy projects. FPC and Lazarus should not follow that bad example, since it would restrict the use of newer target platforms to the use of the new semantics - an idiocy par excellance :-(

In the IDE (both Delphi and Lazarus) it would bind the use of new features (refactoring, widgetsets...) to the new *semantics of the programming language*! But while the Delphi IDE is bound to an specific compiler version, in Lazarus it's at least possible to specify an older FPC version for legacy projects. This feature would be broken when the LCL has to be modified for any idiocy of newer compiler versions :-(

> the Delphi VCL and RTL interfaces, I'd wait for Delphi "X" before > changing anything, or for the death of Delphi, whatever happens That's like saying FPC cannot evolve without Delphi.

I really wonder what's the reason for the breaking modification of property handling - if not Delphi compatibility.

That should never be the case! FPC is a product on it's own - delphi compatibility should be a "nice to have".

And that's why a *compiler* should not define new standards! A language can evolve, and new front-ends can be added to an compiler, but the other parts of an compiler should not depend on changes to the front-ends (languages).

Look what happened to Borland when they trying to wait and see what .NET or Visual Studio does before they support those features. Always playing "catch-up" is a recipe for disaster and you will ALWAYS be second best.

The dominance of Borland, in the development system area, has been broken many years ago. Since that time it's a stupid idea to invent new wheels, because they will be broken by the market leader very soon. The Delphi language could have been made more popular by providing a VS plugin - as has been done by RemObjects. This product has survived as Prism, while Delphi.NET had to be trashed very soon.

As mentioned some time ago, CodeGear and FPC/Lazarus could cooperate very well, and together they could place alternative multi-platform development systems, that could stand against VS and .NET. Delphi could adopt the widgetsets and LCL from Lazarus, and the cross-platform and 64 bit compiler from FPC, while FPC and Lazarus could use the Delphi help contents, and could continue to set new standards and offer native development systems (IDE) for all supported platforms at the same time. Otherwise CodeGear will have to spend some more money on the development of their own compilers, what IMO will result in the next - and possibly final - financial desaster.

Another interesting product with little competition were the support of Modula and Oberon (like) languages by the FPC. Based on the same (FPC) compiler it would be possible to write multi-language projects, like it's possible with .NET. IMO this is the way how breaking language features could be added, and the well known problems with the stone-age Pascal language could be cured, instead of resulting in endless debates over source code formatting and other fruitless "innovations".

DoDi

The consistence has been broken, by updating only the handling of properties, without updating Inc() as well. There is no requirement that Inc() can only work with addresses, and that these addresses must be provided by a single source. Inc/Dec have been compiler (optimization) hints since ever, and should continue to work in this intended way. But we should stop this fruitless discussion here, and move it to an FPC group.

As long as FPC macros take no arguments, another possible workaround were generic inline functions. I never had a look at according FPC features, and currently are somewhat clueless about how to proceed.

DoDi

Hans-Peter Diettrich wrote

As mentioned some time ago, CodeGear and FPC/Lazarus could cooperate very well, and together they could place alternative multi-platform

BTW: I don't believe CodeGear exists any more. Embarcadero on the other hand doesn't seem to have any incentive in cooperating with FPC in any way. I also think it will be mutually beneficial, but then again I am only thinking in terms of developers, not in terms of Embarcadero "only for making money".

Regards,
- Graeme -

> As mentioned some time ago, CodeGear and FPC/Lazarus could cooperate > very well, and together they could place alternative multi-platform BTW: I don't believe CodeGear exists any more.

I'm not sure, but IMO now it's a daughter of Embarcadero.

Embarcadero on the other hand doesn't seem to have any incentive in cooperating with FPC in any way.

Not yet - maybe after the next Delphi desaster? ;-)

I also think it will be mutually beneficial, but then again I am only thinking in terms of developers, not in terms of Embarcadero "only for making money".

I wouldn't find it so bad when Embarcadero cared for marketable products, keeping Delphi alive, while Lazarus/FPC would make the trendsetters and provide IDEs for all supported platforms. In contrast to Lazarus, Delphi "X" will be a crosscompiler only, running only on Windows.

DoDi