I'm currently in the process of rewriting some old AutoCAD plugins from VBA to VB.NET. As it turns out, a (rather large) part of said plugin is implemented in LISP, and I've been told to leave that be. So the problem became running LISP-code in AutoCAD from .NET. Now, there are a few resources online who explain the process necessary to do so (like this one), but all of them takes for granted that the lisp-files/functions are already loaded. The VBA-function I'm currently scratching my head trying to figure out how to convert does a "(LOAD ""<file>"")", and the script is built in such a way that it auto-executes on load (it's a simple script, doesn't register functions, just runs from start to end and does it's thing).
So my question is. How can I load (and thus execute) a lisp-file in autocad from a .NET plugin?
Ok, there are two ways to sendcommand via .NET.
The first thing you need to understand is that ThisDocument doesn't exist in .NET.
ThisDocument is the document where the VBA code is written, but since your addin is document undependant, it stands alone and you must take the documents from the Application object.
You access the application with:
Autodesk.AutoCAD.ApplicationServices.Application
If you want to transform it to the same Application object as in VBA, with same methods and functions
using Autodesk.Autocad.Interop;
using Autodesk.Autocad.Interop.Common;
AcadApplication App = (AcadApplication)Autodesk.AutoCAD.ApplicationServices.Application.AcadApplication;
The first application has MdiActiveDocument, from where you can call the Editor and send written commands, or call the SendStringToExecute as said in other answer.
The AcadApplication has ActiveDocument (an AcadDocument object that behaves exactly as in VBA).
This document will have the same SendCommand your VBA has, use it the same way it's done in VBA.
If you can explain better the autoexecute part, I can help with that too.
Related
MS Access 2016 running on Windows 10.
I am debugging VBA changes to a MS Access application and am seeing some unexpected interactions between the VBA editor and running code. The steps are basically:
Open the application, which opens startup form.
The startup form_load instantiates an object used by other forms the user may subsequently open.
Open the VBA editor
Using the VBA editor, select a line in any code module and the instantiated objects are set to nothing.
An error is thrown when the other forms using the object are opened.
So basically, the VBA editor action has set the objects to nothing. I have added instrumenting code to confirm this.
Has anyone seen the behavior? Does anyone have thoughts about what may be happening and causing this?
Thanks in advance...
Additional information:
The code instantiating the object in the Form_Load method is:
Set musrInfo = New usrInfo
Where usrInfo is a class module containing user information.
Also, there is no problem with earlier versions of this - I have never experienced the described problem with any other MSA VBA application. The compiled version of this particular MSA file is a bit bigger than 20MB, with little in the way of data tables - only a few parameters, etc. - and more than 13MB in forms, reports, etc.
I hope this helps... Lindsay
And there's more...
- I tried this .accdb file on another PC with Win7/MSA2010 and this
behavior did not occur.
- I then tried it in a different folder on the original PC and it
did not occur.
Maybe these findings will allow a path forward, but I still wonder why this would ever happen - why would the folder choice make any difference?
This is usual behavior.
When making changes using the VBA editor, it may recompile the VB project behind your database. This can be the whole project, or parts of it, depending on the exact change.
Recompiles will clear any variables.
You can change this behaviour, by going to Tools -> Options, under the General tab. See the following screenshot.
However, even with Compile On Demand off, you will have to trigger a recompile for most changes, clearing any set variables.
For classes that need a single instance to be publicly available as long as the database is open, I recommend setting the VB_PredeclaredID to true. That will instantiate the object as soon as the database opens, or the code recompiles. See here how.
I need to drive a testbench with labview.
The test scenarios are written in a languages that can be automaticaly translated into labview diagrams.
Is this an API that allow to create "labview diagrams" from another software ? or with labview itself ?
I agree that LabVIEW scripting is one approach, but let me throw out another option.
If you are planning to do a one time migration from your test code to LabVIEW than scripting is great, but if you plan to regularly update your test code (because it's easier to use the "test" language than LabVIEW) than it could become quite painful to constantly perform the migration every time your test code has changed.
I've had great success with simply putting my state machine inside of a for loop and then reading in "commands" from a text file that was generated using my "test" language (see pic).
For example, to do an IV sweep my text file might say something like:
SourceV, 5
ReadI
Wait, 1
SourceV, 6
ReadI
This image is greatly simplified - I'm not using a state machine and I don't show how to use "parameters," but I can provide a more comprehensive example if needed. Again, I've had great success doing this with around 30 "commands" controlling multiple instruments and then I generated the text input using VBA or Python.
It's called LabVIEW scripting. You will need to enable an option in the VI Server page in the options dialog to see the relevant features.
A few things to note:
Scripting isn't complicated, but you do need to be aware of how LV code is built.
While scripting is public, it was initially created as an internal tool. There are still corners of it which are incomplete.
Scripting code can be tedious. If you can get away with it, try creating templates of code.
NI has something called CodeGen, which I believe are a series of functions which make some scripting easier, although I never really looked into it.
Windows XP
The small company I work for just started using this command-line software and it's rather confusing and tedious. I was wondering if it would be feasible to make a GUI frontend and how I would start going about it.
If possible, I would like to have it get data to fill in dropdown boxes and such, but at the very least I'd like to be able to hit a button and perform whatever task. I have never done anything like this before so any help at all would be appreciated.
Thanks
There are two options here:
If the command line exe calls a dll or assemlbly to do the work, then you can work on a front end for the DLL based on the methods that it exposes (ie you can cut out the command line front end completely.
Alternatively you need to wrap the process that the command line runs in and catch its output, and pass it input as appropriate. There's a guide on how to write such a wrapper here: http://support.microsoft.com/kb/305994 (This one is based on writing the wrapper in c#).
One comment though - while it would be possible to do this in VB.Net using the illustrated techniques, doing it in VB6 would be much harder, or even impossible.
We have a bunch of vbscript snippets that are stored in a database. They are created by our users and are used during some complex calculations.
We are using the microsoft scriptcontrol to execute them. As we are switching to 64bit applications we cannot use the scriptcontrol anymore and therefore we are going to start using CodeDom and vb.net instead.
The problem is that we still need to support all those legacy vbscripts until they have been converted to vb.net scripts.
The scripts only contain simple functions taking arbitary number of parameters and do some caluclations on them. As I'm a C# developer I do not have that much experience with vbscript contra vb.net syntax.
Is it easy to convert vbscript code to vb.net (using regex or similar)? Got any pointers or things that I should think of? Or should I just wait until all scripts have been converted by the users (may take a while)?
If you have Option Explicit Off in VB.Net, quite a lot of vbscript code will be ok, but one problem you'd have is that in VB.Net you can't just execute a script by itself, so even if the code might work without any conversion you might not be able to run them in the same way since you'll need to compile them into executables before you can run them. If each script can be executed indepentenly of each other, then you'll either need to compile one executable per script, or have one master executable with a big Select Case in there to call the relevant code depending on command line parameters.
I'd suggest that it might be worth waiting for the users to convert them though and also keeping Option Explicit On and letting the users go through the scripts and add datatypes and similar, since it's quite possible that might find quite a few bugs in your scripts.
The short version
I've got a Word Addin in VB.net and VSTO that exposes a COM compatible object via Word.COMAddins.Object, so that the addin functionality can be called External to Word, without accesses to Word itself being cross-process.
The technique worked in VB6, but with VB.net, it still works, but it's much slower than the same code running directly from the addin via a task pane, as if the calls are all cross process when they shouldn't be.
x
The Long version
This addin essentially does tons of processing on Word Documents.
The addin can be run in two ways.
from within Word, using a taskpane
externally, via a set of classes
exposed to COM (because I have to
provide access to the functionality
to VB6 client apps.
BUT, here's the rub. Anyone who's ever done Word automation knows that code that runs perfectly acceptably INPROC with Word (in this case the instance of the ADDIN that Word itself loads), will generally run unacceptably slowly out of process (or cross process).
This app is no different.
Ages ago, I made use of a handy trick to circumvent this issue.
Create a Word Addin as usual
Expose an object via the
Word.COMAddin.Object property that
will let external code access your
addin.
In your external project, instead of
manipulating Word directly, Use the
Application.COMAddins collection,
find your addin, retrieve the
exposed COMAddin.Object property
from it and then call a method on
that object that does the work.
Of course, the call to your COMAddin.Object object will still be cross process, BUT, once execution is in the addin that is IN PROCESS with Word, your addin can now perform all the Word object manipulations it wants and it's fast because they're all in-process calls at that point.
That worked in the VB6 COM days.
But, I put together this VB.net vsto addin, and expose my addin object via the RequestComAddInAutomationService function of VSTO's Connect object
I can make calls into my addin externally and they all work exactly as I would expect them to, except they're all +slow+, very much like the calls into Word are still being performed cross process even though the code making those calls to Word is part of the addin dll that was loaded in-process by Word!
And slow as in a factor of about 10 to 1; what takes 3 seconds to run when run directly from the ADDIN via the task pane, takes ~30seconds to run when called from external code through the COMADDIN.object object.
I'm guessing that I'm running into some sort of issue with .net APPDOMAINS or something and what +really+ constitutes cross proc calls in .net, but I've found nothing so far that would even hint about this sort of thing.
My next step, barring some mystical insight, will be to code up a repro, which could get tricky because of the shear number of elements in play.
Any thoughts?
I've made the same observations with my VSTO Word add in. What I'd like to add here: When you add your procedure as a click handler to a button:
`this.testButton.Click += new Office._CommandBarButtonEvents_ClickEventHandler(YourProcedure);ยด
and implement your expensive procedure in "YourProcedure", you can call into Word's UI thread using
this.testButton.Execute();
This is not an elegant solution either, but maybe useful if you happen to have buttons ready in a CommandBar.
Unfortunately, the Event hook technique Thorben mentions wouldn't work for my particular situation.
So I'm closing this question out with the workaround that I mentioned in comments and I'll repeat here...
Well, not a perfect solution, but I have found +a+ solution. It involved a timer, so it's definitely suboptimal Essentially, when the addin is loaded by Word, (ie during the STARTUP event), initialize a timer (a WINFORMS timer, not a threading timer), and set it's interval to 500. When External code connects to the addin via the COMADDIN.OBject property, and makes a call into the addin, set a variable flag, which is being polled by the timer. When the timer sees it set, it resets the flag and performs the action.
It's not the clean solution I'd have preferred, but it's fairly easy to implement, moderately easy to understand after the fact, and it definitely avoids the slowdown of xprocess COM calls into Word.