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.
Related
I just converted one of the FsXaml demo programs to an interpreted F# script so I could experiment with it and learn. It wouldn't run, and the interpreter gave me the following error message:
System.NotSupportedException: The invoked member is not supported in a
dynamic assembly.
at System.Reflection.Emit.InternalAssemblyBuilder.GetManifestResourceStream(String
name)
at FsXaml.InjectXaml.from(String file, Object root)
at
FsXaml.App.InitializeComponent() at FsXaml.App..ctor()
at
FSI_0002.main[a](a argv)
in C:\Users\bobmc\OneDrive\FSharp\Learning\WPFExamples\FsXaml\demos\WpfSimpleMvvmApplication\WPFApp.fsx:line 104
at .$FSI_0002.main#() in
C:\Users\bobmc\OneDrive\FSharp\Learning\WPFExamples\FsXaml\demos\WpfSimpleMvvmApplication\WPFApp.fsx:line
109
Can I use the F# interpreter with FsXaml? Thanks to all for your help.
Unfortunately, WPF and scripts don't play well together.
The exception occurs within the WPF runtime itself - FsXaml.InjectXaml is using a XamlObjectWriter to populate the type with the contents from the XAML file. This type doesn't work if you're using a dynamic assembly (like FSI), which unfortunately means that FsXaml will likely never be able to work from FSI.
That being said, even if there was a way around this, it'd be of very limited use. WPF also has restrictions that make it not play well with a scripting scenario, such as the "only one application can ever be created within a given AppDomain" restriction. That one makes it so closing the "main" (first) window makes it so you can never open another one. As such, I haven't prioritized trying to make this work in FSI.
I'd be happy to accept contributions if somebody has an idea of how to make FsXaml play more nicely within the context of FSI, but at this point, I don't see a good solution for that usage scenario.
Edit: FsXaml 3.1.6 now includes functionality to make this a lot easier. It works well, provided you don't close the main window, or you use dialogs. There is a demo application/script illustrating this.
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.
I couldn't find a similar question here.
I have a PRO*C program named pro_c.pc. How can I call and execute this in a piece of PL/SQL code?! Could someone give me a simple example?!
You can link external libraries (Windows DLL or UNIX ".so" files) to Oracle and then make them callable via PLSQL. This has been around at least since Oracle 8i.
This though requires DBA privs on the server to set this up, and is probably not a recommended approach these days .... but useful for crunching huge data.
See here for more details.
Calling a actual program directly, as opposed to a library function from PLSQL would be done indirectly via DBMS_SCHEDULER as #Justin suggested as the easiest way, creating a program with the PROGRAM_TYPE as EXECUTABLE. See here for more info.
A couple of things to note when doing this, the program will run as the (assuming UNIX) "oracle" user - bringing with it some security considerations, e.g. if the program creates a file it will be created as owned by oracle, and so might not be accessible to an "application" user. The program will run on the Oracle database server.
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.
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.