You should be able to set EventInvoke to Synchronous to prevent event handlers from showing up in the command history, but then you have to live with the limitations of synchronous event handlers.
The question is if it are really limitations: I have a tree control in a palette. When I doubleclick an item the c:MyProject_MyForm_MyTree_OnDblClick event will be released. When the eventinvoke method is set to asynchronous then I see this name in the commandline. In earlier times I was sad about it. But now I changed my program style and my thinking about it:
1. For all the image and text buttons which invokes events in a modeless form (or palette or dockable) that need user input or are going to create objects in the drawing I set the event invoke to asychronous and I define a custom event handler name: ^C^Cblockman_drawsingle. If the user presses such a button, an active command will be cancelled and in the commandline I read only BLOCKMAN_DRAWSINGLE. And I startet to love its advantage: this event can be repeated by pressing ENTER key.
2. Checkboxes, optionbuttons or any controls which events have not effects in the drawings are calling synchronous events anytime and never asynchronous.
3. ListViews, treeviews and so on, which events can also cause changes in the drawing or provides userinputs are called synchronously, too. But they call generic commands.
(defun c:MyProject_MyForm_MyListView_OnDblClicked (intRow intCol)
;; [...] do something
(dcl_sendstring "BLOCKMAN_DRAWSINGLE\n")
); c:MyProject_MyForm_MyListView_OnDblClicked BLOCKMAN_DRAWSINGLE is called asynchronously. Yes, I work with global variables in this case. But there are also other ways to make sure that the asynchronously called command can get the information from the called event.
Working this way that has the same advantage as mentioned in my first point of this list.
Having a look at (dcl_sendstring "BLOCKMAN_DRAWSINGLE\n") that leads me to a question, Owen:
When I send a string like (dcl_sendstring "^C^CBLOCKMAN_DRAWSINGLE\n") it has obviously not the same effect as OpenDCL calls this event name as mentioned in number one of this list.
Is there a way to cancel a running lisp or an active command via lisp (please not via sendkey {ESC}) OR
Could dcl_sendstring parse the given string for ^C^C to cancel a running lisp or an active command before sending the rest (in this case "BLOCKMAN_DRAWSINGLE\n")?
Fred
