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
Related
Does every window running use System.Windows.Forms.Form?
The title says it. From Java to C++ to Visual Basic to Console Apps. Does every compiled window use the class System.Drawing.Forms.Form?
No.
In .NET, System.Windows.Forms is (essentially) just a tool to draw windows, but it is not the only tool. Other languages have their own tools; Java has the Swing libraries, Python and Perl have several other GUI toolkits, each which do things differently. Console Apps use an entirely different way of presenting information. How things are drawn not only depends on the language, but also the GUI API used. For example, a window might be entirely drawn using C++ and DirectX and custom drawing routines; these would not use .NET at all, nor any underlying tools that .NET uses. That same window might be drawn with C++ and Open GL; the same data might be displayed, but the routines invoked to draw it would be different. In fact, you could do all the drawing with assembly if you were really masochistic!
Short answer No.
System.Windows.Forms.Form is an abstraction used by the WinForms .Net library to interact with the actual Windows provided by the OS.
Other languages have other abstractions: Java could use Swing or AWT or any other UI library which offer different ways to draw forms.
Likewise C++ could employ an abstraction over the OS provided objects (i.e. the MFC library) or use the Windows API directly.
All the UI libraries need in the end to use the Windows API to draw their windows, but not all of them do it to the same extent, so .Net's UI libraries will use some of the same API calls as Java's or C++'s UI libraries.
I'll update this answer if I find a good explanation of how the UI and UI libraries work on windows.
I remember reading a good one not long ago with some of the history and the changes in Windows 8 but don't remember where.
I was just thinking. C# has Winforms/WPF, Java has Swing and other frameworks, C++ has QT and so on; is it possible to create an application without using a Framework?
Putting aside the practicality of it, I'm just curious. How would one create an application that Just Works(tm) without needing external frameworks?
Two options come to mind:
Classical Win32 applications written in C. I don't know if standard Windows SDK API also counts as an "external framework" in your book, but that's as low as it gets.
DirectX/OpenGL games written from scratch with your own homebrew framework (not external, right?) There you get to do all the drawing yourself - although again, you use a pretty big library of primitive drawing functions.
If you want even less "framework", you'll have to code your own OS and drivers. :P
C# needs .NET Framework, not WinForms (which is an optional library used by some application). The same with Java.
Unmanaged (native) applications usually use some runtime library - the library of common functions. You can write a native application without any library - the compiler lets you do this, but you will need to (re)write lots of common functions, eg. for string manipulation etc..
Firstly, what is a framework?
Really a framework is just a bunch of code that is provided to you. You could, at least in theory, write the same code yourself. In that case you wouldn't be using a framework.
Your application can only do what the operating system allows it to do. Your program cannot directly manipulate the graphics card for example. So you have to use the APIs of your operating system in order to do anything.
So you are going to be calling into other code. (unless you write your own operating system). You will also being using another framework or api to get stuff done.
Yes. How: in the way that the frameworks you mentioned are implemented.
From a Windows point of view, you would register your window with Windows, then listen to window messages and react as required. Everything would be up to you - from drawing the window to building controls.
My goal is to control an application from VB.NET. There is no API, and I do not have the source, only the compiled EXE file. Is there a way to find the opened application, find a button within the application, click a button and know it was clicked? Is there a way to read the contents of a textbox within the application?
Yes, with Windows Vista (or Windows 7, or Windows Server 2003 and later) there are "UI Automation" APIs.
There are managed options; System.Windows.Automation is one, shipped with .NET 3.0, as part of WPF... Though System.Windows.Automation was shipped as part of WPF, it does not require that the target application uses WPF.
You can read more:
the UI Automation blog.
the MSDN Magazine article - talks about using PowerShell with System.Management.Automation.dll (an alternative to System.Windows.Automation).
Blog post by Samuel Jack - describes using System.Windows.Automation to automate the Paint.NET program (C#).
CodeProject article #1 shows using UI Automation to test an installer
CodeProject article #2 provides a basic introduction to using System.Windows.Automation
Yes, you can, but first it might be easier to use 'AutoIt' as a prototyping script first to find the application. Look for the handle of the window of that application, enumerate through that window's child controls, look for that text box specifically and the button...once AutoIt prototype works, then dive into the real coding and it would be possible to use P/Invoke's to enumerate and find the windows, get the handles of it and perform the automation on it...
Have a look at the sample in C# from Stack Overflow posting Calling SendMessage (P/Invoke) keeps crashing. The OP was trying to access a third party window application, to extract texts and to use that texts within their program...notice how in that given link, 'FindWindow' was used to iterate through the child windows of the main process's window.
Yes, but you will have to resort to using native API calls such as EnumWindows and EnumChildWindows for example. Take a look at How To Enumerate Windows Using the Win32 API. It is for Visual Basic 6.0, but the concept is the same.
I am considering doing some automation of tasks on my Windows desktop (e.g. sorting through large collections of music/text/photo files, etc...).
Seeing how my main area of developer expertise is Perl on Unix, I'd prefer to stick to Perl for coding the business logic of whatever I need done, just for the sake of development efficiency.
The question is, if I want to slap some GUI on top of the work (ala Perl::Tk on Unix), what are my GUI toolkit options and which one would you recommend using?
Please note that I'd like this question to be a good learning opportunity to other SO users, so I would welcome ANY answers even if they don't necessarily satisfy my own limitations/needs listed below, although notes elaborating on how your solution relates to these considerations would be very welcome.
My considerations are mostly driven by the fact that I want a quickly developed tool for personal use to save myself time on tasks I now do manually.
Main consideration is Perlishness of development - "Easy things should be easy and hard things should be possible" as a Perl slogan goes. Especially the first part :)
Prefer (but not insist) to be as native as possible as far as components used. E.g. rather re-use Windows' file open dialog vs. having some custom Java dialog.
I would prefer to use something that would have a small learning curve (e.g. no need to learn intricacies of OLE/COM), since the goal here is speedy development of tools I need to simplify my life as opposed to developer education which I concentrate on areas more relevant to my day job :).
But I definitely would love to get exposure to something new/cool while doing this, e.g. if some nice Monad based GUI components are suggested I'm definitely curious.
Performance matters (e.g. I may need to display a directory listing with >10000 files), but is not of paramount concern - I am a pretty good GUI designer and developer and can always architect my app and design a GUI to scale well if needed).
I would strongly prefer (though not insist on) a framework that does not force me to compile stuff. e.g. Perl libraries are more preferable to custom Java stuff I need to compile. But if the framework is perfect in all other respects, I'm open to a compiled solution (as long as it doesn't required me to purchase Visual Studio or somesuch - I want to build a Windows GUI front-end for personal use, not invest in becoming a Windows developer).
I'm pretty open and flexible outside of above constraints. Some ActivePerl/Strawberry Perl libraries, MS PowerShell based components - heck, if nothing better shows up I'll just install Apache on my PC and build a web front-end :)
With respect to "perlishness" of the interface, I'd suggest plain old Tk. Unfortunately, it looks quite antiquated and non-win32-ish.
If you want native widgets, I think your best shots are using the native Windows GUI via Win32::GUI or Wx. I have no experience with Win32::GUI, but Wx is quite nice. It does, however, have a rather steep learning curve and the interface isn't very "perlish". The C++ roots show a little bit (for better or worse).
There are a few Tk-replacements that are actually thin wrappers around Tcl/Tk (I think Tcl::Tk and Tkx). They look more modern than Perl/Tk, but I have no hands-on experience with these either. If you're developing for Windows only, have a look at ActivePerl which comes with (I think) Tkx. Their ppm4 package manager is written using it and looks pretty nice!
There are a number of options listed in perlfaq3 and some additional ones that aren't. I'm only familiar with the Tk-based ones.
Perl/Tk has the most "perlish" interface but it hasn't been updated to take advantage of tile (native/themed widget) support in the current version of Tk (and probably never will be). Tkx uses a different bridge to Tk. It allows access to everything in Tk (and it's faster, too) but the syntax is less perlish. Tkx is designed to be a thin wrapper over Tk; you have to consult the Tk documentation for most things and translate for using it from Perl. The Tcl/Tk module uses the same bridge as Tkx but supports a syntax that's mostly the same as Perl/Tk.
Whether or not you need to compile anything depends on which version of Perl you use. If you use Strawberry Perl you'll probably have to compile something no matter what toolkit you choose. ActivePerl distributions have included Tkx since sometime in the 5.8.x cycle and stopped bundling Tk as of 5.10, although it's still available via PPM. Tcl/Tk is available from CPAN but I haven't been able to get it to work with the Tk library that comes bundled with ActivePerl; you may need to install Tcl separately to use it.
Personally, I used to use Perl/Tk but now use Tkx.
While Tk and Qt are also available (more general frameworks originally intended for other languages, on which you can also use Perl), and Tk probably most popular as it's been around longest, Win32::GUI would seem to meet your requirements best. If you like WISIWYG GUI designers, you could use Loft on top of Win32::GUI, but you don't have to if you'd rather do everything programmatically.
Shameless plug - I am in the process of writing a pure Perl GUI toolkit, XUL::Gui that renders its GUI using Firefox. It allows you do anything Firefox can (XUL, HTML, JavaScript, Flash, other web tech). Firefox uses the native look and feel of the OS (or any other theme you want), and is available for most platforms.
use XUL::Gui;
display Window title=>'My Application',
Button( label=>'click me', oncommand=>sub{ shift->label = 'ouch'} );
It's currently under development, but probably stable enough to start working with. The idea is to be as simple and perlish as possible. Nearly all boilerplate is optional, with sensible defaults. For example, the Window tag is only needed because I wanted to title the window.
The module is up on CPAN. I'd encourage anyone to take a look, and send me feature requests or bug reports.
I'd just stick with Tk myself. It runs on Windows and you already know it.
I would choose GTK because because it has a study guide (at the moment I'm using Wx and there's plenty of available source code in Perl using Wx but no actual official documentation .. apart from some articles, so no book ... no official stuff) , if not Qt is an option also , and it has some proper documentation(but I haven't tried it).
Tk has very big problems and I won't use it.
As for your performance problems ... I'm pretty sure no decent application would be concerned if it's displaying 100000 or 10^100 files , since very few fit on your
screen, so you can do some clipping.
If it is just to get a simple GUI on top of your scripts then the easiest path is VB.NET (or C#). That is what I do.
With Visual Studio's designer it is just a matter of designing the form, double click on the button that will that start processing, add code to read off parameters from the GUI elements (e.g. file paths in TextBox'es) and pass the information to the script through environment variables or command line parameters.
Example from one of my applications (used by real users):
Dim inputFolder As String = txtInputDataMGFfolder.Text
Dim outputFile As String = txtOutputMGFfile.Text
Dim ws As WshShellClass = New WshShellClass
Dim objEnviron2 As IWshRuntimeLibrary.IWshEnvironment = _
ws.Environment("PROCESS")
objEnviron2.Item("INDIR") = inputFolder
objEnviron2.Item("OUTFILE") = outputFile
'It may or may not help for this: the user dialogs for selecting
'files may change the current directory and running the Perl
'script or one of the .pm files would fail.
ws.CurrentDirectory = appPath()
ws.Run("%COMSPEC% /K perl -w MultRawPrepare.pl", 1, False)
Note that use of Windows Script Host for this may not be strictly neccessary, but if it
is then this is needed:
'Requires adding reference to project:
' menu Project/Add Reference/COM/Windows Script Host Object Model
' Note: "Windows", not "Microsoft".
'
'Note: the DLL may not be registered;
' D:
' cd \WINNT\system32
' regsvr32 wshom.ocx
Imports IWshRuntimeLibrary 'For WshShellClass.
appPath() is defined as follows (and required "Imports System.Reflection" in the beginning of the VB.NET file):
Public Shared Function appPath() As String
'"[Assembly]" requires System.Reflection
Dim strAppDir As String = _
Path.GetDirectoryName( _
[Assembly].GetExecutingAssembly().GetModules(False)(0).FullyQualifiedName)
Return strAppDir
End Function 'appPath
User selection of files or folders is easy to add, but is helped by HOW-TO instructions and a little bit of boilerplate code.
The Express edition of Visual Studio for VB.NET is free.
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