A piece of ruby code using win32ole
require 'win32ole'
ie = WIN32OLE.new('InternetExplorer.Application')
ie.visible = true
ie.gohome
Some code using win32api
require "Win32API"
message = "This is a sample Windows message box generated using Win32API"
title = "Win32API from Ruby"
api = Win32API.new('user32', 'MessageBox',['L', 'P', 'P', 'L'],'I')
api.call(0,message,title,0)
First one opens up internet explorer and the second one displays a message box.
Simply saying both seems to be able to access the OS and make it do stuff. Is win32ole a subset of win32api or is it the other way around? What is the difference between the two?
win32ole is for interoperating with libraries & applications that have been written to act as OLE/COM servers, see What is COM? for an explanation of that technology.
win32api interacts with the operating system API (Win32) which is also where OLE/COM are implemented, but win32ole exists to conveniently abstract away much of the complexities involved in making use of COM via its lower level API.
Related
I have been using JavaScript in Windows Scripting, both in .JS files and .WSF files, for several years, but I have found that there are some methods that are not recognized when I put them in a script that is executed outside a web page that are valid in a script on a web page. I know that different browsers support different versions of JavaScript, and MSDN has a page that describes which functions and methods are supported in which Internet Explorer and Edge browser versions:
https://learn.microsoft.com/en-us/scripting/javascript/reference/javascript-version-information
but it does not say which methods are supported in Windows Scripting.
Does the version of JavaScript supported in Windows Scripting depend on the version of Windows, the version of Internet Explorer installed on the computer, or some other factor or combination of factors? Is there a way inside the JavaScript program to detect which version of JavaScript is being used as it is executed?
Its a common mistake to make but the Windows Scripting Host supports VBScript and Microsofts own JavaScript implementation called JScript based on the ECMAScript standard. In fact, it can support a number of scripting implementations through its support for Active Scripting languages.
While it shares many similarities with JavaScript, they are not the same (yes, they came from the same place, but that doesn't mean they didn't diverge afterwards). When you use .js files outside of the internet browser (the only browser to support Active Scripting was early versions of Internet Explorer, pre Edge) they are executed using a host program, in this case the Windows Scripting Host. This also applies when using .wsf files.
Edit: I've also updated the wsh tag info as it states javascript can be used, which is incorrect and why so much confusion arises around this topic.
Useful Links
Answer to What will be the status of the term JScript in MSDN?
JScript Language reference (via archive.org before Microsoft nuked it)
Answer by #dai (who was an engineer on the Microsoft JavaScript Team) regarding JScript versions
i started heavily studying Jscript about 2 years ago. From my experience
no classes
no imports
no Lambas
no "let"
no "const"
no fun
this is the state of what JS looked like when i first began programming back in 2012. At this time all the above features was the gonna be the next big thing in EcmaScript 6.
So my educated guess would be EcmaScript 5.
you can still make classes with the traditional ES5 syntax.
function FunctionButClass(a,b){
this.Square = function(){ return a*b; }
}
var squared = new FunctionButClass(4,4).Square();
the prototype syntax works as well.
function PrototypeSyntax(a,b){
this.a = a;
this.b = b;
}
PrototypeSyntax.prototype.Square = function(){
return this.a*this.b;
}
also note that the entirety of the DOM is absent, so no document.getElementById("") everything is run through the WScript.CreateObject("")
note2: the DOM IS available in Jscript through .HTA files. But remember
WScript.CrateObject("Scripting.FilesSystemObject");
now becomes:
new ActiveXObject("Scripting.FilesSystemObject")
I'm working on a desktop application for OS X using Ruby-Tk, and I would like to provide an Apple Events interface for the application. This means that the application would define a dictionary of AppleScript commands that it would respond to (corresponding to Apple Events being sent to the application), and users/other applications could script the Ruby-Tk application with AppleScript commands. Other scripting languages support such functionality--Python through the py-aemreceive library at http://appscript.svn.sourceforge.net/viewvc/appscript/py-aemreceive/ and Tcl through the tclAE library at http://tclae.sourceforge.net/. I've been looking for similar functionality in Ruby and have come up empty.
One possible mechanism is the rubyobjc bridge, which provides a low-level interface between Ruby and Objective-C, but this gem appears to be little-used and is sorely lacking in examples and documentation, so I am not sure if this would be a fruitful path to pursue.
NB: MacRuby might work but it is not compatible with Tk, so that rules out MacRuby. Also, RubyOSA and rb-appscript are not what I am looking for--they allow Ruby to send Apple Events to other applications, not receive them.
In the absence of other alternatives, it appears I am going to have to write my own Ruby wrapper for the portions of the AppleEvent C API that I need: mainly AEInstallEventHandler and related functions. Fortunately Apple still supports this API even though it has been relegated to "legacy" status in Apple's developer docs (though, interestingly, it is not deprecated). I'll either integrate these functions via Ruby's ffi gem or, more likely, via Ruby's C API (which I still have to dig into); using the C API directly would reduce the need for dependencies on other gems/modules. If this goes well I will release it as a gem.
Regarding Donal Fellows' comment, my need is for custom AppleEvents--the ones supported via Tk in the docs he recommends can likely be accessed through calls to Tk from Ruby's Tk interface.
You might want to check the appscript library (note: Seems to only work with the OS X-provided Ruby), or try using MacRuby, which wraps pretty much everything of the APIs available in OS X, even the C ones.
I have designed a custom Windows application in C#. Now, I would like to automate it using Win32OLE library in Ruby. I have absolutely no experience in using Win32OLE, so I would like to know when I create a new Win32OLE object using:
customApp= WIN32OLE.new('MyApp.Application')
it gives an error since it returns a null Win32OLE object.
Do I need to have a COM file for my application? If so, why is it needed? Also, could someone point me to all the files required by my custom application before I start trying to automate it using Win32OLE.
What exactly do you want to automate? If its by simple actions (tab,enter,etc. mimic the keyboard plus waits for some windows actions) you can use AutoIt.
http://codesnippets.joyent.com/posts/show/829
Everything starts with:
require "win32ole"
au3 = WIN32OLE.new("AutoItX3.Control")
It comes as a requirement of the rubygem watir. But you can see if there a more simple way to install autoit (its a .dll) for your ruby needs.
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