On 8 November 2011 12:43, Florian Klaempfl <florian@f...> wrote: > So you wanted to break existing stuff other people probably used? It is > indeed one of FPC's policy to avoid breakage of exisiting code.
Break what existing code? I searched all of FPC, Lazarus, Lazarus CCR and MSEgui - there was no existing usage of THelpEvent. Lazarus's LCL implements there own version of this. So I really didn't see an issue in changing it in FPC. If you (or Marco - the one that declined my proposal the first time round) have an example where it would break existing code, I would love to know about those please. Now if you want to go down the "delphi compatibility" route, well then FPC is in the wrong anyway! Neither Delphi, nor Kylix has THelpEvent defined in the Classes unit, but rather in the Forms.pas unit. So what delphi is FPC really trying to be compatible with in this case? > Or did you propose a TFPHelpEvent? I can't remember the details, but I think I proposed that too. In the end, I simply defined what I needed in fpGUI itself. Clearly the latter is the path of least resistance (Martin should agree with his experiences of MSEgui) - though I do prefer to use existing classes from FPC (as a first option). As I said, in the end I defined what I needed in fpGUI itself, using existing types in the signature, like THelpType and THelpContext - which ARE both defined in the RTL, doesn't reek of Windows'ism. TfpgHelpEvent = function(AHelpType: THelpType; AHelpContext: THelpContext; const AHelpKeyword: String; const AHelpFile: String; var AHandled: Boolean): Boolean of object; -- Regards, - Graeme - _______________________________________________ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal