Programming with Odcl - few questions

hello

I have few questions regarding programing with Odcl:
1. I'm wondering is there any way to omit (or how to program) all these C:..FUNCTION.. definition. Any click on any control (button, picture etc) is connected with C:FUNCTION
For example, after 20 click i run 20 FUNCTION. I don't see them at command line but i see all of them when i try use my UP arrow on keyboard. If i want to back to my value before ODCL starts is pain (i need to go thru all C:) -> modeless form
2. Any way to buffer Hatch control? When hatch is to dense it takes few second to draw.
3. Is it possible to draw on Picture control with DASHED line?
4. With regular DCL we can scroll on ComboBox with mouse. Value are change without opening the combo list. I think it was more comfortable? Also i can very quick select something from the list, just entering the first letter.

Thanks

author=kruuger link=topic=1249.msg6689#msg6689 date=1270153249 wrote:
hello

I have few questions regarding programing with Odcl:
1. I'm wondering is there any way to omit (or how to program) all these C:..FUNCTION.. definition. Any click on any control (button, picture etc) is connected with C:FUNCTION
For example, after 20 click i run 20 FUNCTION. I don't see them at command line but i see all of them when i try use my UP arrow on keyboard. If i want to back to my value before ODCL starts is pain (i need to go thru all C:) -> modeless form
2. Any way to buffer Hatch control? When hatch is to dense it takes few second to draw.
3. Is it possible to draw on Picture control with DASHED line?
4. With regular DCL we can scroll on ComboBox with mouse. Value are change without opening the combo list. I think it was more comfortable? Also i can very quick select something from the list, just entering the first letter.

Thanks

1. Just remove the C: from the function name in the events panel, then resave your project.
2. I don't think so, maybe Owen can look into that for a future build.
3. No, anther good feature request.
4. Anther good feature request.

1. Just remove the C: from the function name in the events panel, then resave your project.

i try this but error occurs "error: too few arguments"
i also delete these C: at my lsp file and nothing

author=kruuger link=topic=1249.msg6691#msg6691 date=1270155388 wrote:

1. Just remove the C: from the function name in the events panel, then resave your project.

i try this but error occurs "error: too few arguments"
i also delete these C: at my lsp file and nothing

Oops, I think I got that one confused.
Removing the C: from the lisp allows you to hit Enter to repeat the last commend\function.
I don't think you can hide the functions in the history list....

:(

Thanks anyway

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.

author=owenwengerd link=topic=1249.msg6696#msg6696 date=1270175268 wrote:
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

The prefix "^C^C" is translated to two break characters when OpenDCL calls an event handler. You can do the same by prepending your command with two break characters (chr 3) before passing it to (dcl_SendString).

BTW Fred, the system you describe is exactly how I envision an ideal design to work, where "commands" triggered by user actions are implemented as and executed as typical AutoCAD commands, and everything else is executed as a function. This is probably a good topic for a tutorial; it's not difficult to grasp once you understand it, but it may not be obvious at first to newcomers.