I think, an application wide KeyDown event would be very useful. Not only for a helpsystem. I have added a handler chain to Application. Just add your keydown event with:

Application.AddOnKeyDownHandler(@AppKeyDown);

This keydown is invoked, if no other component used the key (KeyVK_Unknown).

Mattias

Under Delphi TControl has the three properties

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

The LCL has the same, but they were not published, because help is not implemented in TApplication yet. I have published them.

I think, Michael is right.

Mattias

Right.
I never used the help code of Delphi6, but it has OnHelp for forms and for Application. And it defines the IHelpSystem interface in HelpIntf.pas. Maybe we can write something similar, so that adding help to applications becomes more easier.

That's the idea of IHelpSystem and the other interfaces defined in HelpIntf.pas. It also supports to combine several Help Systems. This is needed for the IDE as well.

Under Windows, Help was pretty much designated by the OS. Under Linux we aren't quite so limited (or structured as the case may be.)

Yes. That's why I suggest to add some helper functions to the interfaces. For example searching the default browser depends on it (win32 -> registry, gtk -> search executables, gnome -> ???).

Don't know.

Mattias

Tony Maro wrote

I guess one more quesiton before we jump in with both feet is, how does Kylix handle it's help system? Or does it?

Just remembered that I once looked at Kylix 1 and that it was still installed.

This version uses HyperHelp (Bristol Technology Inc) It's interface is pretty like good old winhelp. The kind of files look the same as win32 help, however, my XP help doesn't understand them.

Marc

Oops, think I sent this from the wrong account first time. If this is a dupe then sorry:

Ah... was this implemented after Delphi 4? Perhaps it's just been too long since i used it.

Okay, I'll try to make the appropriate adjustments to my code...

But then we must decide that the official help system for Lazarus will be HTML files (or whatever.) I wasn't ready to make that judgement call. Or perhaps we could have some sort of an OnHelp event for the Application object that could be set... then you could plug in a component like mine that handles the help system the way the user wants.

With that kind of addition, it would be easy to make a component that drops on a form which would launch help from an external library, or whatever. Or, a different component that would launch HTML files. Or perhaps a third that would encapsulate it all within the application itself. And this would be able to happen without changing any of the help pointers on the controls. Just change the help handler component.

See what I'm saying? Kind of a pluggable help system to fit the programmer's needs. Under Windows, Help was pretty much designated by the OS. Under Linux we aren't quite so limited (or structured as the case may be.)

I'm working pretty heavy on this because I think this is one of the things that will make a huge difference in Linux applications - how many Linux apps do you know that have HELP, much less context sensitive help? If it's an easy thing to do, then applications written in Lazarus will easily be of greater quality than most apps written for Linux.

I guess one more quesiton before we jump in with both feet is, how does Kylix handle it's help system? Or does it?

-Tony

Tony Maro wrote

Under Delphi, wasn't there a "helpid" property or something like it that was used for the context sensitive help system?

HelpContext, at the level of TWinControl.

This should be standard behaviour of the TWinControl component, there should be no need to add a separate control. Your problem of who gets to see the keystroke first is then solved.

Michael.

Under Delphi, wasn't there a "helpid" property or something like it that was used for the context sensitive help system?

Is it possible to add this property to the TControl object (or wherever it's more appropriate?)

I'm working on an HTML context sensitive help system and my idea is for a TComponent that you drop on a form that will watch keystrokes for F1. It would then see what control had focus and check it's help id property. Then it maps that help id property to a list of html files provided at design time, locates a proper browser on the computer and opens the html document with it.

The only thing I'm not sure of is how to grab the keystrokes with a message before any other control grabs it.

Currently I'm using a context help system like this, but I have each control's OnKeyDown event triggering the help file. That's kind of kludgy and painful if there's a lot of controls.

Is there a message my control could watch for that would let it see the keys before the controls? Or that would grab leftovers after the controls processed everything they could... and if the latter, would F1 naturally fall through?

Thanks,

Hmm.. Looks like the TApplication.OnMessagehandler ? There you can catch all events if you want.

MArc

Hi Tony,

In Delphi I think help was handled at the TApplication level. I think there was an event OnHelp or something similar to that. When F1 got pressed this got called and if a method was attached, the it would be called. This method also worked for context sensitive (in Windows ctrl-F1, same in Lazarus ?).

If it's done the central way, the application handles capturing the keystroke, not each form. That way you don't need to worry about making a component to do this for you (though you should still be able to do it your way for special cases if you want to).

I kind of like this way of doing things, as it centralises help rather than having to add a handler to each form. which gets messy (is this what you meant ?). This way all that needs to be added to a TWinControl (or perhaps TControl) is a HelpID : LongInt property. This way each control can have a context help associated.

I may have got parts of this wrong. Wouldn't be hard at all to add in the help tag I think. The help management system itself ? Don't know.

Cheers
DC

But then we must decide that the official help system for Lazarus will be HTML files (or whatever.) I wasn't ready to make that judgement call.

Personally I don't think that HTML or not is that big of a problem. Sure, something else is more efficient, but doesn't matter much.

However HTML with an own small subset interpreter, or a 30 MB footprint browser, that is the dilemma.

So while I'm not against HTML, I don't think regular browsers are an option. To slow, requires too many resources.

The alternatives are:

a)
Using a small browser: for instance Dillo - small, fast, needs only gtk+ (not gnome).

b)
Creating our own help browser. The TurboPower InternetPro component (TIpHtmlPanel) in components/turbopower_ipro/ already works for simple HTML pages (i.e. no images). So, we have a HTML viewer component for the content, a TTreeView for the TOC, TSynEdit for the examples.

It would nice to restart the discussion about the IDE helpsystem. I think, extendable is the keyword. Anyone should be able to easily add some help texts and send them to one of the developers, and adding the text should be as easy as applying a diff. That's why we need editing tools and a simple format.

Mattias

May I again point out that the new fpdoc system is ready, officially included in the compiler utils - it will be distributed with the compiler by default, and can be used to generate any format you like, HTML and LaTeX being defaults. The sources themselves are simple XML (much like HTML for formatting), and a simple GUI editor is available for it.

Currently, we're making enhancements to be able to include arbitrary pieces of text (topics) as an addition to the pascal-unit oriented topics which exist now. This is done especially to accomodate IDE help systems.

Michael.

It's not the LCL that sends the keydown event to the form before the wincontrol. It's the gtk. If the user presses a key, the gtk sends a keypress event to each parent widget down to the widget of the wincontrol. If you activate KeyPreview, the LCL does the same as the VCL: The form processes the Key event before the wincontrol. And that's why, it will result in two keydown events for the form and one for the wincontrol. For Delphi compatibility the gtk interface should skip key messages to parent wincontrols. Probably there are some other incompatibilities in the key handling. Any volunteers?

Also, can we publish keypreview?

Done. Although it does not make much sense yet, for the above reasons.

Mattias

Mattias Gaertner wrote

Once for the form, and once for the TEdit. Normal.

It generates the form event first. Your description of what the event is supposed to do is generate the event only if nothing else has processed it. In order to process at the control and fallback to the form if not processed, I think it would make sense to ask the focused control first, then the form, unless the form.keypreview is set?

Also, can we publish keypreview?

-Tony

I've been playing around with this event, and found that it is called twice for each keypress.

Once the Sender object is some blank object that claims it is a TWinControl (at least a descendant of) but has no name in the name property, and then a second time for the actual object that has focus.

I never could figure out what the first object sent to the event was... a few if (Sender is XXXX) let me know that it's at least a TWinControl descendant, but it wasn't the TEdit control that I was hitting the key in, because when compared as (Sender is TEdit) it wasn't...

And like I said the name property of the object in the first call is blank.

-Tony

Once for the form, and once for the TEdit. Normal.

You can find out the class with writeln(Sender.ClassName);

And like I said the name property of the object in the first call is blank.

You found a bug. The form name was not loaded. I fixed that.

Mattias

Am I the only one who carries on conversations with himself? ;-)

Okay I see what's going on now. KeyPreview just plain doesn't affect things. The form always gets keypresses (and fires it's OnKeyDown event) before the controls on the form, regardless of the KeyPreview state.

-Tony