The On-line help system

[colorrr]

Since the actual activation of the help system (call to the static 'help server' method) has to be programmed by whoever is doing the interface, that means you are pretty much free to define the activation action that has to be taken by the user.
If you press F1, it would trigger among others the KeyPressed event, passing an EventObject (KeyEvent inherits this one) as a parameter. With that object you are able to access the source component of that event.

All the events that are key driven or mouse driven has a source object that you can pass to the help system.

For the key events this would be the component that has the focus in the moment. For the mouse events it would be the component under the cursor at the moment of the event.
Check out these events as they carry some more information that is useful.

That seems like a good way to make context sensitive help.

To be honest I did not check out the Java Help system. I think the big download (20+ MB ??) stalled me the last time I tried.

I'll have to make the effort someday.


Color

[Gary Thomas]

My point in asking about the interface is that having the game code components implement an interface implies that the help system will make a call on some object method defined in the interface. Since the help display is initiated by the component, it seems to me that it is the help system which should be implementing an interface, called by the component, and passing the help identifier as a parameter.

Cheers

[colorrr]

Sure, if you prefer to call a method and pass the help identifier this is fine with me. How you get hold of that identifier would then be up to you. You could store a new variable in each class and then when someone invokes the help you have to check that the object that has the focus of the help has this variable, get hold of the value and pass it on, or do it in another way.
This would basically mean going back to the first option envisioned to pass information. The identifier of the help item could be stored as a String in each class or in another constant value container class to organize all the identifiers (making sure there are no duplicates).

The reasoning behind the calling objects implementing a java interface (not a class), was to make the code easier for the caller:
upon receiving the help request event, he would just pass on the object that is the focus of the help, and not worry if the object has any help attached and to fetch the identifier in order to pass it. Passing the object means the help system would then check if the object implements help and fetch the necessary information.
The process would be automatic.
Upon creating an instance of the source object the help identification data would be filled out.
I think this is the better solution. If you have to touch the class to add a help identifier variable, you might as well implement an extra interface to smoothen the help execution code.

You choose the way that serves you best.

[Gary Thomas]

I see what you meant now.

Unfortunately, in many cases, the help "object" will just be an image drawn on a panel, a picture of a unit, for example. Such an "object" will actually be an area of the panel, rather than a real object. This is also true of the map. The only object available is the mouse event, which does give the coordinates, but doesn't tell you what is actually there, and hence what type of help is required.

It would be possible to make sure that every distinct area of the map has an associated object, implementing the interface, and return that object. It is just that that is not the way it works now.

On the other hand, with a keen and experienced gui writing team, fixing that should be no problem.

I do prefer your system as leading to greater encapsulation.

Cheers

[colorrr]

Originally posted by Gary Thomas
Unfortunately, in many cases, the help "object" will just be an image drawn on a panel, a picture of a unit, for example. Such an "object" will actually be an area of the panel, rather than a real object.

This is also true of the map.
The only object available is the mouse event, which does give the coordinates, but doesn't tell you what is actually there, and hence what type of help is required.

It would be possible to make sure that every distinct area of the map has an associated object, implementing the interface, and return that object. It is just that that is not the way it works now.

I think the the mouse event has a source object too. That would have to be confirmed.
And if not, I think there is a method somewhere (maybe the SwingUtilities class) that returns the current object visible at the (mouse) coordinates. Of course if it happens to be a click on a map/image this would return the panel, and not the map square.
This panel could have routine, taken some input coordinates, to calculate and return the current hex information as an object.

I am pretty sure all these problems can be fixed, so that it could always be possible to pass an object of some kind.

On the other hand, with a keen and experienced gui writing team, fixing that should be no problem.

I do prefer your system as leading to greater encapsulation.

It get the impression a interface overhaul is on the wishlist.
It seems to me it could be good to discuss more (Oh no! More discussion! :-) how that interface should be before deciding exactly how to incorporate the help into this.

What we could do with the help system is implement the two ways of accessing the system: with an object implementing the help interface or just passing a string paramater.
That way, the help interface should be useable in the existing and a possible new GUI.

Maybe I could look more into the GUI as well, if there is no one doing this work at this time. I find the subject interesting.
I have been playing with the idea of making a full screen interface to clash. . . . any opinions?

Jorgen

[colorrr]

I forgot we already had an GUI thread so the last phrase is irrelevant, is was written before I read the other thread.