.NET call in LISP: Pause while waiting for user input?

[Anonymous]

I am having our VBA code (written by others now long gone) converted to .NET.  The .NET functions ideally should be called by our existing lisp functions that once called VBA routines.

My problem is that when lisp calls a .NET function that creates a dialog box asking for input, the lisp function keeps running and so doesn't receive the variables supposed to be set by the .NET function. 

If I run the all of the calls separately, everything works.  If they're combined in a single LISP function, all goes haywire.

Is there a way to pause after a lisp routine call of a .NET function to wait for input?

These functions produce the desired result when run separately but not when combined.

Run this .NET command:             

  (command "prefix”); sets a layer name prefix

Then run these LISP functions that look for a variable generated by user input in the .NET "prefix" function dialog box

  (layer_m "TEXTL") ; creates layer name in quotes with a prefix added

  (layer_m "MEDM")

  (layer_m "LITE")

[Anonymous]

I did a test to see the problem was not from a dialog box input. It was from user interaction with the AutoCAD Editor. I guess your .NET code may call Application.DocumentManager.MdiActiveDocument.Editor.GetXXX() that eventually open the door for all following LISP functions to go through, run in parallel with the ongoing .NET function. Just remove all editor inputs (GetPoint, GetEntity, GetString...) and your code may be fine. My code is working well with an OpenFileDialog to select a file but does not allow all following LISP functions to run.

Another easier way to do is to call LISP functions inside your .NET program at the end. Just use SendStringToExecute after the .NET function is finished. So we will not face this issue of concurrency in AutoLISP.

-Khoa

[dgorsman]

Rather than defining a command in .NET and calling it as (command "MYCOMMAND"), consider defining a LISP function and calling it as (myCommand arg1 arg2...).

[Anonymous]

I agree that the ideal route would be to put all in .NET, but as this entire effort is a stopgap on the way to Revit implementation, we're trying to do as little recoding as possible.  Since no one in our office knows .NET or has time to learn it, all we want to do is use our current lisp functions that call VBA modules - and wait for and accept the returned data - and substitute .NET clones of our current VBA commands.

I've done some web searches and see that there's a "lispfunction" concept in .NET that might help.  Unfortunately, I'm not the programmer.  We may try going this route first.

[Anonymous]

"Rather than defining a command in .NET and calling it as (command "MYCOMMAND"), consider defining a LISP function and calling it as (myCommand arg1 arg2...)."

I'm not sure what you mean by this.

[Anonymous · Accepted solution]

I did a test with LispFunction to define a LISP function instead of a .NET method and saw it solved the problem of AutoLISP concurrency. Thank you for your hint!

Now you can run a single LISP file with those commands:

(Prefix); sets a layer name prefix
(layer_m "TEXTL") ; creates layer name in quotes with a prefix added
(layer_m "MEDM")
(layer_m "LITE")

.NET command does not work well with LISP functions whenever a user input is required in the AutoCAD Editor, it will let all following LISP functions behind this .NET command to run through. So just use all LISP functions will fix the issue.

To convert a .NET command to a LISP function, we need to use the following template:

[CommandMethod("Prefix")]
public static void PrefixCommand()
{
    // Implementation
}

[LispFunction("Prefix")]
public static ResultBuffer PrefixCommand(ResultBuffer buffer)
{
    var result = new ResultBuffer
        {
            new TypedValue()
        };
    // Implementation
    return result;
}

-Khoa

[Anonymous]

Khoa, thanks for trying this out.  I'll pass it along to my programmers, who yesterday told me they'd done this before in some instances.

[Anonymous]

No problem Paul. Please let me know if all LISP functions may help.

-Khoa