Calling commands from modeless forms

[Fred Tomke]

Hello,

I have a modeless form with some buttons on it. It should look like the toolbar from Corel, Photoshop or Illustrator. The buttons have no other task as to call a command in the command line. In OpenDCL 5.1.2.3 I made it this way:

• modeless form
• KeepFocus: NO
• EventInvoke: 0 (Keep Focus)
• picture button
• EventInvoke: 1 (Allow Command)
• Event OnClicked activated
• Name for OnClicked event function: name of the commandline option: A

I have added a sample for this. You can use it in 5.1.2.3 and you will see that you can invoke a commandline option by pressing a button.
But using 6.0.0.16 (and some releases before), it won't work anymore. I get an error message (in German language; try to translate: Cannot return to LISP. Needs a point or optiontitle.).

Is it a wanted change in OpenDCL 6, so I have to rewrite my code?

Fred

[Kerry]

Can't reenter LISP.
Point or option keyword required.

Same for me ... works in 5.1.2.3, not in 6.0.0.9 or 6.0.0.16

Interesting method Fred.

[owenwengerd]

The revamped event handler code generates an async event handler call by sending the event handler and its arguments as a "command" like this: "(<handler> <arguments>)\n", hence the error.  I added code to Alpha 17 to send just the handler name as a command for any event handler that gets no arguments.

BTW, something to think about would be how prefixes might be given special meaning.  The \C\C prefix already has a special meaning, but prefixes like ' could also signify something.  In this case, I thought it wuld be nice if the "command" would be visible; that could be accomplished via prefix perhaps.

[Fred Tomke]

Thanks, Owen, but there are some questions left - maybe I missed something or I didn't quite understand.

The revamped event handler code generates an async event handler call by sending the event handler and its arguments as a "command" like this: "(<handler> <arguments>)\n"

Just for understanding the change: Wasn't it so already in 5.1.2.3?

[...] but prefixes like ' could also signify something [...]

Do you mean transparent commands?

[...] In this case, I thought it wuld be nice if the "command" would be visible; that could be accomplished via prefix perhaps.

What did you mean by a "visible command"?

Fred

[owenwengerd]

The major changes to the event handling code changed in 6.0, but it's possible that this particular change occurred before 6.0. Event handler prefixes could mean whatever the code interprets them as. By "visible", I mean that the user would see the command at the command line.

[BazzaCAD]

I would love to make some commands invisible to the end user, if possible...

[owenwengerd]

I'm talking about making them visible (event handler calls are currently always invisible). Anyway, I've tweaked the code to leave them visible when they are not prefixed with "c:". I think this makes Fred's sample much more user friendly.

[BazzaCAD]

Oops sorry, thanks.

[Fred Tomke]

Hi, Owen,

[...]it's possible that this particular change occurred before 6.0[...]

Maybe, but this little detail from my initial message must have been changed after 5.1.2.3 . 

[...]event handler calls are currently always invisible[...]

Normally, I prefer invisible commands. I don't know if this hits the same notch, but I'm looking anyway to supress the event handlers of controls whose EventInvoke property was set to asynchronous. In this case the batch of commands is listes in the recent command list (see screen shot).

Maybe it is a good idea to use a certain prefix to make event handlers visible for some cases.

Fred

[owenwengerd]

I don't think there's any way to prevent event handlers from showing up in the command history. I'm referring only to whether they are visible at the command line.