OpenDCL Event Callbacks

[Jim Short]

First, I am testing my project in Acad2004, Acad2010, and BricsCADV11P.
Brics is giving me problems with the continuous firing of a C: kill focus event that I must ESC out of.

The other two apps work fine.

Up arrow, displays previous previous c: callbacks on the command line in Brics and Acad2010.
Acad2004 does not display the call backs on the command line.

Could Brics problem have something to do with the previous call back function being able to be run again by just pressing enter.

js

[Fred Tomke]

Hi, Jim, it may depend on the type of form you use: modal, modeless or palette? Can you post a small sample to reproduce? The called event functions will be echoed in a modeless or palette if EventInvoke is set to AllowCommand.

Regards, Fred

[roy_043]

I have also stumbled upon Jim's 'displays previous c: callbacks' problem:
http://www.opendcl.com/forum/index.php?topic=1618.msg7964#msg7964
and I thought it was a Bricscad-only problem. But it seems that this issue also exists in AutoCAD 2010.
To me this behaviour is undesirable for three reasons:
1. It confuses the users of your program.
2. Errors can occur if a user inadvertently fires such a callback in the wrong context.
3. It makes the program look 'unfinished'.

Is there no way (other than setting EventInvoke to 0) to solve this? Is it perhaps possible to return to the old, AutoCAD 2004, behaviour?

[Fred Tomke]

Hello, roy_043,

Is it perhaps possible to return to the old, AutoCAD 2004, behaviour?

It's new to me, that it was not so in earlier releases. I remember the ObjectDCL times. There was such a property too. And it's even necessary. In a modal form all the events will be called in a document locked state. To be sure to get access to the drawing, you have to close the form and to finish the close event.

In a modeless form or a palette it is similar: when using KeepFocus, the event will be called in a "locked" mode. To get access to the drawing you have to leave the event at first. That can only be solved using a command (AllowCommand). OpenDCL is using such a thing like SendString so the event will be started as a command.

What can you do? I have a palette, too with a library of signs the user can choose and draw. He can choose a sign by double clicking in a list, in a tree or by pressing a button - as the user prefer. Since I don't like the output of (c:signothek_sc_palette_dwgpreview1_OnDblClicked) or (c:signothek_sc_palette_lsitview_OnDblClicked 1 1), too, I created a command sc_signothek_draw, which is called from the events. In the end the controls are using EventInvoke KeepFocus and within the event functions I use an vla-sendcommand that invokes the start of the command after the event function has been finished. In this way you have to make sure, that the command can be used. Just define a global variable, and only it is set and contains valid data, let your function do the desiered job.

The other thing you can do is to overwrite the event function name and set the EventInvoke to AllowCommand. Then the user can see your command which is more readable.

I used the fact as an advantage: Once the user has selected a sign, he can repeat the command just by hitting Enter to draw the same signe once again. The same way as AutoCAD works.

By the way: You can break the current command by typing ^C^C in front of the command name.

In the end it is this no matter of OpenDCL: it is the same way I have to call events asynchronously from a palette built in C#, for instance.

Regards, Fred

[roy_043]

Vielen Dank Fred!

I have attached a small sample of the first method you describe (or how I understand it). It is a simple dialog with only one button. But something strange happens. If I start the program with DrawMyLineStart the button's OnClicked event automatically fires. Is something wrong with my dialog or is this perhaps a Bricscad bug?

[Fred Tomke]

Hi, roy,

Unfortunately, I have to tell you, that OnClicked wasn't called when I call DrawLineStart. I've added some notifications. I'm not sure if the behavior you've mentioned is caused by BricsCAD.

BTW, when I'm not sure when an event will be called I add a princ as the first line of the event function.

Code (autolisp) Select Expand


(defun c:DrawMyLineStart ( / )
  (command "OPENDCL")
  (dcl_Project_Load "DrawMyLine" T)
  (princ "\nBefore show\r\n")
  (dcl_Form_Show DrawMyLine_Form1)
  (princ "\nAfter show\r\n")
  (princ)
)

(defun c:DrawMyLine_Form1_TextButton1_OnClicked (/)
  (princ "\nButton click\r\n")
  (setq *globalData* '((0 0 0) (1 1 1)))
  (vla-sendcommand *activeDocument* "DrawMyLine ")
  (princ)
)

(defun c:DrawMyLine ()
  (princ "\ndraw Line\r\n")
  (if *globalData*
    (progn
      (setvar 'cmdecho 0)
      (command "_.line" (car *globalData*) (cadr *globalData*) "")
    )
    (princ "\nError: data missing ")
  )
  (princ)
)

Code Select Expand


Befehl:
Button click
DrawMyLine
draw Line

Regards, Fred

[Fred Tomke]

roy_043,

please disable the form's KeepFocus property (I don't mean EventInvoke) in the DrawLine sample.

Regards, Fred

[roy_043]

Thank you Fred for testing this. Setting KeepFocus to False doesn't solve this in Bricscad. I will submit a support request.

[owenwengerd]

I can reproduce the errant OnClicked event in Bricscad 11.