First at all, I come from Visual FoxPro 9.0.
All my apps made on VFP can execute dynamic code from any events (Buttons, Grids, Forms, etc).
Example:
lcFile = "c:\test\myDynamicCode.txt"
=EXECSCRIPT(FILETOSTR(lcFile))
Is it possible to execute it on Pascal?
Thanks...!
The default install of Lazarus comes with a set of components under the general title "Pascal Script" which can be used to implement a scripting engine and debugger - see
http://wiki.freepascal.org/Category:Pascal_Script
and
http://wiki.freepascal.org/Pascal_Script_Examples
The scripting engine can compile (to byte code) and execute scripts written in a dialect of Object Pascal which is close to, but not identical with, the Object Pascal which Delphi implements. The package comes with code wrapper around a number of the supplied Lazarus/FPC units which implement components which are intended to be equivalent to a number of Delphi's components.
In short, you should find that you can use Pascal Script to write and dynamically execute Object Pascal code equivalent to the majority of what you could write and compile in FPC. As you will gather from the code examples in the second link, the Pascal Script engine allows you to add custom functions defined in your own Lazarus/FPC code and make your forms and classes accessible to, and scriptable by, a Pascal Script script.
If you need a scripting engine to implement another language, there are 3rd party libraries available to assist with this. Most were written for Delphi but should translate easily to FPC + Lazarus. Examples include
TP Lex/Yacc: http://www.musikwissenschaft.uni-mainz.de/~ag/tply/
Delphi Compiler Generator: http://www.soft-gems.net/index.php/tools/delphi-compiler-generator
So, in short, if what you are wanting to do can be expressed in Lazarus/FPC code, there is a very good chance it can be executed in Pascal Script code. If you need an engine for another scripting language, TP Lex/Yacc and DCG will allow you to write your own scripting language, but be aware that it will be a lot more work than using the Pascal Script components.
Btw, I don't know whether Linux is of any interest to you, but the Linux version of Lazarus/FPC also comes with the Pascal Script commponents.
Related
What is the difference between VB and VBScript?
VB is a full-fledged programming language which can be used to create compiled applications, while VBScript is a sub-set of VB and is a scripting language that can be used to run a set of commands, similar to an old-school DOS batch file. Generally, a scripting language can not be used to create a full-fledged binary application and it can not be compiled down to a executable binary file.
This is a very old question, but existing answers are outrageously vague, and/or fail to identify the most important stuff, when they're not just plain wrong. Not going to repeat what other answers already indicate, but the following differences are missing from the other answers:
Scopes
VBScript code doesn't need procedure scopes: it can be written as a [drumroll] script that just executes a bunch of procedural operations top-to-bottom.
In VB6/VBA executable statements can only exist inside procedure scopes.
Types
In VBScript everything (variables, function return values, etc.) is a Variant (i.e. pretty much a duck, like in JavaScript). It is illegal to declare an explicit type when declaring a variable. The As keyword is illegal!
In VB6/VBA everything defaults to an implicit Variant, but good VB6/VBA code uses explicit types where applicable.
VBScript is a variety of VB, just as VB6, VBA, and VB.NET are. They're all different, some of them dramatically so.
VBScript is a "lightweight" subset of Visual Basic with limited syntax that is used for scripting purposes (like routine task automation) rather than application development.
While Visual Basic code is compiled into binary executables, VBScript code is interpreted and runs within a host environment (e.g. Windows Script Host or Internet Explorer).
Also VBScript's code can be ran in VB6. Maybe that confuses you.
But all VB6's codes can't be ran in VBScript.
VB is application development tool (like, desktops, web based application)
And VB script is scripting language, it can not independently developed application.
I was asked by a friend to write a simple GUI containing some charts and selections of common commands for an application he wrote in Forth. However, I have basically zero knowledge about Forth, only that you can't write a GUI in this language (at least that's what he told me).
Now I've been wondering what other programming languages you would suggest which do interact well with Forth and provide libraries (e.g. Java Swing) for interface programming?
Note: I'm still a beginner in programming, and my experiences so far are limited to Java, HTML, CSS, JavaScript, and some C#.
Win32Forth comes with complete Windows GUI and words to use all user32.dll and gdi32.dll functions. It also has a great development environment and windows form creator and editor. Very easy to create user interfaces with it.
SP-Forth allow developing applications with GUI and library WinLib: http://spf.sourceforge.net/ UI libs: http://spf.sourceforge.net/docs/devel.en.html#ui
I would suggest XHTML and Co. (i.e. CSS, JavaScript, XSLT, HTTP) to create user interface (GUI) and interact with Forth. In most general case you include an http-server into Forth system. In some special cases a Web browser object can be embedded into Forth application (for example, using COM on Windows).
Also on Windows you can use HTA (HTML Application) — quite simple solution. HTA can be started from Forth as well as Forth from HTA.
Another way is to use Qt framework (some Forth systems can have bindings).
Yet another way — just use API to underlying system (like user32.dll and gdi32.dll on Windows). Some Forth systems contain GUI-libraries that are based on underlying system API.
Also as edge case, user interface can be implemented in any language as shared library or as separate process with IPC (inter process communication) to Forth system.
In any case, usually GUI is created using special languages, libraries or APIs. GUI is not a subject of Forth as general-purpose programming language.
Bernd Paysan's MINOS may be a way to write GUI code in Forth:
https://bernd-paysan.de/theseus/minos-1.html
Adding a GUI to a program written in Forth is no different from the same problem in any language. You either have to write graphic code yourself or be able to call graphic libraries. In both cases on e.g. MS-windows you have to call functions present in DLL's and you need the documentation of those functions. Most serious Forth's allow to call DLL's. Of course libraries that are internal to a different language are less easily used, but why would you want to? You then commit to that language and are better off using that language from the get-go.
Forth being an interpreter you can couple a plot program easily via a pipe, but that is a one way street. It may be viable if the plot program has the interaction ( such as enlarge, change scale, crop, print etc.) you need.
I want to use VBScript to read values directly out of memory of another running application.
I can't seem to find information on using ReadProcessMemory() in VBScript.
I intend to use this in Quick Test Pro to do screen scraping of an application that needs testing.
This application does not use any standard controls and using QTP's OCR abilities does not provide us with reliable results.
We currently have code written in AutoIT that reads values of this application directly from memory and converts it to ASCII. But we want to remove the reliance on that and using VBScript from within QTP would be ideal.
So can anyone tell me how I can read values from an executable in memory using VBScript?
You can't do this in VBScript directly. As Josh Einstein's comment above mentions, it's impossible to call native Windows API functions directly from VBScript. There are two major reasons why this is the case. First, it would pose obvious security risks for code written in such a scripting language to be able to call native code directly. And second, VBScript only has one data type (Variant), which is not going to work properly with the return values of most of the Windows API functions.
Instead, you'll have to wrap the native API functions that you need in an ActiveX DLL (COM automation object), and then call functions from that library from your VBScript. The wrapper DLL would be designed specifically for VBScript-interoperability and would take care of any necessary data-type conversions, exposing only Variant types and containing all of the necessary (or potentially necessary!) error handling routines. Using VB 6 is the quickest and easiest way to do this and doesn't even require you to learn a new language, but you can also do this from C++, if you're comfortable there.
I'm completely new to COBOL, but I'd like to take a look at the different options for GUI programming on Windows. I don't really like Tcl/Tk, though. Is there some resource for developing a Windows GUI in COBOL in the same manner that one would develop a GUI in C?
Thanks!
I used MicroFocus version 2.0 and it supported creating Windows GUI forms with an event driven model. They are now on version 5.1. Although the full version is quite expensive, there is a book with a stripped down learning version here:
http://www.murach.com/books/mcb2/microfocus.htm
check out http://www.netcobol.com/
in particular http://www.netcobol.com/products/windows/cobol.htm
For OpenCOBOL, there is an embedded Tcl/Tk layer by Rildo Pragana (author of TinyCOBOL, his TC Tcl/Tk sample compiled and linked for OpenCOBOL, first try), but if you don't like Tcl/Tk, his toolkit places almost all of the GUI on the Tk side, so:
There is also a GTK+ layer sample
Source code looking like:
*> Add a text entry field
CALL "CBL_OC_GTK_ENTRY_NEW"
returning gtk-textentry
END-CALL
*> Connect code to the text entry, passing the entry widget
SET callback TO ENTRY "CBL_OC_activate"
CALL "CBL_OC_G_SIGNAL_CONNECT"
using by value gtk-textentry
by reference "activate" & x"00"
by value callback
by value gtk-textentry
END-CALL
...
*> window is ready to show
CALL "CBL_OC_GTK_WIDGET_SHOW"
using by value gtk-window
END-CALL
*> Start up the event loop, control returned when GTK main exits
CALL "CBL_OC_GTK_MAIN" END-CALL
*> Something terminated the GTK main loop, sys-close or bye or
display "ending..." end-display
FLTK worked, but I haven't posted the trial source codes.
GtkHTML widgets worked too.
A Gambas COBOL GUI layer is hosted on Google Code
ROOT/CINT can interpret OpenCOBOL generated C, and then you can get interactive graphs from WORKING-STORAGE.
Qt tested fine, but C++ requires more, albeit thin, wrapper source, so GTK was targeted instead.
Pretty much anything that can be wrapped by C, can be called by OpenCOBOL. That includes the native Microsoft WinAPI.
While working on the FAQ I found that using Vala really opens up the field for extending COBOL. As both OpenCOBOL and Vala produce intermediate C, the mixing potential is nearly unlimited, and developers can benefit from efforts by either project. I recommend checking out Vala for use from COBOL.
See the OpenCOBOL FAQ, section 5 for working samples. Screen capture image from source code listed at http://opencobol.add1tocobol.com/#does-opencobol-support-the-gimp-toolkit-gtk
I need to write an app that reads a config file with info on the menu bars it needs to create.
Normally, I'd just use java, but I need the application to have the least run-time dependencies possible, this includes not forcing the user to download anything, even JRE, let alone something like NET Framework.
So I need something that can compile to an EXE (windows only for now), and that will allow me to CODE the GUI, so I can dynamically create it from my config.
BTW: something like C++ is a bit too low level, all I need is to create menus, and display HTMLs in a panel.
How about wxPython together with py2exe?
There is a nice tutorial on how to do it here.
If Java's too high-level and C++ too low-level, there ins't much in-between. Maybe Delphi?
I wouldn't totally write off using Java and/or Python for a few reasons.
1) py2exe can compile your Python code to an exe.
2) GCJ can compile your Java code to an exe.
Delphi is best chose for you. Because Delphi compile source code into native x86.
Unless you have serious reasons to avoid interpreted languages, I would suggest you better look into ways of packaging or compiling interpreted scripts because doing this will likely reduce your learning and development time.
I would write a simple GUI in Tcl/Tk, and then package it as a Starpack.
ActiveState provides a distribution (ActiveTCL) and a decent editor (Komodo Edit), and it is fairly easy to get simple GUIs going with Tk. Check out TkDocs for some hand holding.
Once you're done, you can package your code, a Tcl runtime, a database, and a virtual filesystem, all into a single executable that you can easily distribute.
Earwicker is right. You can use HTA:
http://www.interclasse.com/scripts/htanotepad.php
But if you know C++, then creating this type of an application is actually very easy with Visual C++. Use MFC, and statically link everything. You can draw the menu in the resource editor, and attach events to the menu items. I wouldn't use HTML if I were you. Just use regular Windows controls. But if you're really set on using HTML, you can embed a Browser control in the formview.
Have you considered D ? It has a syntax that is like a mixture of Java, C++ and Python with the ability to make native windows apps. The tutorials on dprogramming.com are great to get up and going with the language. For quick GUIs you'd be interested in The D Forms Library and the Entice Designer.
Here are some short video tutorials to get up and running with Entice.
Alternatively, have you tried Qt & Qt Creator? It takes a lot of the hair pulling out of C++ Programming and it's also cross-platform.
You say:
all I need is to create menus, and
display HTMLs in a panel.
A lot like a Web browser, then. If it's going to run on Windows, then the user has IE. Why not use IE to do all the work for you?
You can make something a lot like an .exe with IE, called an .hta:
http://msdn.microsoft.com/en-us/library/ms536496(VS.85).aspx