VLIDE causes weird behavior with non-modal dialog

Hi

I am working on a little tool, that causes some weird reactions in AutoCAD during development (While VLIDE is opened).

The tool itself is a screenmenu replacement (I wrote about it last year) and is working fine on AutoCAD and BricsCAD.

If only AutoCAD is active everything is fine. The MouseMovedOff event is triggered correctly.

When VLIDE is active I cannot activate AutoCAD without the Button from VLIDE. Usually I need to press it 3-5 times to return to AutoCAD

What I can see is, that, if I move the mouse from AutoCAD to VLIDE over my form, the MouseMove events are fired correctly (they cause highlighting of lines of the screenmenu) but the MouseMovedOff event is not executed (it removes all highlighting) which causes the last highlighted line to stay that way.

If VLIDE is closed and another application is activated all the events are fired fine and there are no problems.


Has anybody got an idea how to work around this?

I tried hooking a command-reactor to "_VLIDE"  but it is not called if I switch to VLIDE by just switching windows (I run AutoCAD and VLIDE on different monitors) because AutoCAD doen't call the command-reactor.

I don't care if a sollution is clean or dirty since the problem only occurs during development and not during productive work, so I would be fine if someone had an idea how to react to "AuoCAD lost focus" and "AutoCAD got focus" to close the form and open it again on entering AutoCAD.

I hope someone has an idea how to solve this problem.

Kind regards

Ingo P

Can you provide a very simple demo project that logs the mouse events to a listbox, along with instructions for how to reproduce the problem?

Hi, I cannot give you any solution for this but I can tell you that this behaviour  is well-known and not caused by OpenDCL. I can reproduce this also when working with non-modal forms from c#. I also have this behaviour after several times of debugging and aborting debug in cause of any error.

Regards, Fred

@owenwengerd
I've build a small test (see attachment)
Just run "ODCL_VLIDE_ERROR"
The box catches "MouseIn" and "MouseOut" while the list catches "MouseMoved"
In and Out immediately print a message to the list while Moved prints one message per second maximum.
While AutoCAD is active everything works fine.
While the VLIDE is active (code is editable) only the List.MouseMoved event is triggered, while the dialog's In and Out events are ignored.

@Fred Tomke
What you say makes me sad because it indicates that the problem might not be a bug in the OpenDCL-Runtime but in AutoCADs implementation of the VLIDE, which would require Autodesk to fix it and we all know how motivated they are in supporting third party developers...

[UPDATE 2013-08-30 12:32]
We found a workaround for our case after realizing that VLIDE is not a command but the Lisp-function (C:VLIDE)
so we added this code to our project:


(defun p:vlr-lispwillstart (a b)
  (if (wcmatch (car b) "(C:VLIDE)")
    (p:dcl_project_unload "screenmenu"))
)
(vlr-lisp-reactor 'nil (list (cons :vlr-lispwillstart 'p:vlr-lispwillstart)))

(p:dcl_project_unload p) is a function we wrote to manage our projects better. it takes wildcards, ignores string cases and closes all opened dialogs of that project. But all this just on the projects that have been loaded by our tools.