Simple Windows Development Tools?

fwc asks: "Over the past few years, I've been fortunate to be able to avoid writing a Windows GUI application, however this good luck is coming to an end. In the next few weeks, I need to write a fairly simple application which will need to display data received from a serial port in a decoded (and graphical) form via a Windows GUI. Unfortunately, my skills in this area are out of date, since I haven't written any GUI apps for close to 10 years. Because this program needs to be fairly small and easy to install, the use of Perl/tk isn't a valid option. What options do I have to build a small application on Windows, without a large learning curve?"

Comments

VB

[ecklesweb]

Unless things have changed in the past few years since I played around with Windows GUI programming, Visual Basic is by far the easiest way to get a Windows GUI app off the ground.

Re:VB

[Fallus Shempus]

I'd agree from a complete programming novice
but you've got a nice free choice (as long as it's not commercial code)
if you have more experiance (especially C++)
http://msdn.microsoft.com/vstudio/express/

Re:VB

[hey!]

I wouldn't dismiss this out of hand either.

Just because you can build a crappy app in VB by following the path of least resistance, doesn't mean you have to.

If it's a one off app with a simple UI that works the way your users would intuitively expect it to, this is precisely what VB is good for. If you think the UI required is "sophisticated", it might not look so for somebody who does a lot of UI work. Things get tricky when you have to coordinate a wide variety of user tasks.

You can also use Visual C#. It's really not any harder This would allow you to build your business logic around interfaces, allowing you to, for example, replace C# implementations with native C or with java or even php based web services later. You can also port to other platforms depending on how good Mono's Windows.Forms package is. Or you could build your app against GTK# and get portability right off the bat if that's important to you.

Re:VB

[#undefined]

what do you mean "as long as it's not commercial code"?

there's no licensing restriction on visual studio express.

4. Can I use Express Editions for commercial use?
Yes, there are no licensing restrictions for applications built using the Express Editions.

taken from here.

Some options:

[hummassa]

1. Graphical IDE: (in order of my recommendation) Delphi (C++Builder if you are too much into C++), KDevelop, Eclipse or VB.

or...

2. You can hire someone (like me!! hmassa at gmail) to do it for you. :-)

Visual studio...

[lscoughlin]

It's sad. Very sad. But if your tied to windows, then Visual Basic is the way to go. If you've got access to vs.net, c#'s gui builder is also pretty slick and the language is far less braindead to use.

Visual Basic

[Sarlok]

It's easy to learn and the GUI designer is also easy to use. What's more, with the new (2005) version, there is a free "Express" edition that you can download from Microsoft.

Visual Basic Express Edition

[PoiBoy]

I'd recommend trying Microsoft Visual Basic 2005 Express edition, in part because it is free but more importantly because it comes with a very easy-to-use GUI designer and a wealth of online help. My understanding is that it's basically a stripped-down version of Visual Studio.

I just started using Windows XP (out of curiosity) after having used Linux for the last six years, and I honestly have to say I've been very impressed with the development tools Microsoft makes available for free.

TCL/TK

[jmac880n]

TCL/TK is small, easy-to-use, and portable over many systems.

In addition, your entire program tree plus interpreter can be encapsulated using a starpack.

Re:TCL/TK

[Twylite]

Kudos to the well-informed parent. Tcl/Tk is indeed an excellent solution. More below.

But first ... Visual Basic is NOT the answer. The criteria were "fairly small" and "easy to install". For most Windows versions you'll have to distribute your VB application in an install package that includes the VB runtime DLLs or the .NET runtime (or get the end user to download them, which is a mission). If you're unlucky you'll have to distribute other MS DLLs like ComCtls as well. Find out more at http://msdn.microsoft.com/vbrun/ . Then there's accessing the serial port ...

For a simpler solution, grab TclKit, a single-file Tcl/Tk distribution. Tcl is ridiculously easy to learn, serial port access is as easy as file access, and it uses Tk to provide a powerful GUI.

You can put your scripts into the TclKit EXE as a resource, creating a single-file EXE distribution of your application. With UPX compression the resulting file will be around 1.2Mb (depending on what extensions you choose to use).

Re:TCL/TK

[Anonymous Coward]

Visual Basic is NOT the answer. The criteria were "fairly small" and "easy to install". For most Windows versions you'll have to distribute your VB application in an install package that includes the VB runtime DLLs or the .NET runtime (or get the end user to download them, which is a mission).

Uh, what year is this? Since Windows 2000, maybe even further back, the VB6 runtime has been bundled with the OS. Even if you do distribute it yourself it's smaller than that TCL/TK distro you point at. And VB6 comes bundled with InstallShield lite to cover 'easy to install'. And upgrading comctl32 was like back in the IE3 days, Jesus.

Now I hate VB6 with a passion but if you're going to bash it get it right.

RAD tools

[morgan_greywolf]

RAD tools are a great and easy way to write GUI apps without getting knee deep in the API (in this case, Win32). Borland's Delphi, C++ Builder, and C# Builder are great tools, and all work similarly, but support different languages and tools... C++ Builder is my personal favorite, but I C# Builder is nice for developing .NET applications. Borland also has a similar tool for Java. And there's always Visual Basic.

wxWidgets

[TheGreatOrangePeel]

I'm guessing that you're going to hear a lot of people saying VisualBasic. Personally, hate VB. You might take a look at wxWidgets. I've only toyed with it myself, like what I've seen. There is also wxDevCPP which gives you a VB style GUI.

Re:wxWidgets

[ClayDowling]

I've gone down this route myself and been very happy. I use Delphi daily, I've written some large VB apps, but wxWidgets was by far the best tool for rapid development for me. Dev-cpp from http://www.bloodshed.net/ was for me the fastest way to get a working C++ compiler up and running, and they have wxWidgets available as an installable module. You can find the latest version on their Community DevPack server.

Alternative....

[ceeam]

Ask yourself - how would you've done it on Unix? Well - Perl/tk may be not an option, but definitely you can write a no-GUI program to receive data from your serial port and store it somewhere. Then make a small web-server (plenty of options - no need to install apache or stuff) and serve your data in graphical form to a web-browser.

Try Realbasic

[Quiet_Desperation]

I do mountains of Windows GUI crap to control my hardware designs via serial port and Ethernet. Realbasic makes it all easy and it's not as annoying as Visual Basic. Nicely object oriented. Even file i/o is OO.

http://realbasic.com/

RealBasic!

[numbski]

http://www.realbasic.com/

Extra credit is that it can compile binaries for Windows, MacOS X, and Linux. I believe there's a demo version to try before you buy.

If you're looking for completely free, unfortunately you may well be sol. KDevelop may be your only option as posted above, but I wasn't aware that KDevelop can give you win32 apps....?

Delphi is decent

[teeheehee]

I can't vouch for VB since I try to avoid it as much as possible, but I worked with Delphi at my last job and recommend it as an excellent rapid GUI development IDE and language.

There are lots of extensions to the component palette which are free (as in beer) and some that are free (gratis) which can be very helpful. I didn't do sockets programming but there are components for that, as well as for graphs. You might be surprised at how quickly you can pick it all up, it's quite intuitive.

Java or .NET

[miyako]

Java with Swing is a pretty quick way to write a GUI. Swing is well documented on sun's website- both with APIs and tutorials available. It also has the benefit of being largely crossplatform (though given your specific task there will probably be some native code that would have to be rewritten).
If you don't want to learn Java, or you would prefer something more native to windows, .NET is a huge step up from the old way of creating windows GUIs. I haven't used it extensively, but it seems to be largely well thought out and well documented (though I still vastly prefer Sun's javadoc to Microsofts .NET documentation). .NET has the benefit of being able to work with most languages you would want to program in.
A few general suggestions if you're rusty with GUI programing that you might want to consider as well:

• Don't use form builder code for actual code. While GUI builders can be a good way to get an idea of the way you want the GUI to look, in my opinion they end up producing really ugly code. It's generally faster and easier to just write it from scratch.
• Sketch out the GUI. Even for a simple GUI it's difficult to design a GUI while looking at code unless you're really comfortable with both the API and with the type of GUI your designing.
• Seperate Logic from Display. It's tempting to put little bits of logic in the GUI code, but if you're going to be supporting the code you're life will be much easier if they are seperate. Essentially you are writing two programs. The program that does the task (in this case, reading the data from the serial port and processing the data) and the program that displays the task. It's fairly reasonable to say that if your program is properly designed, you should be able to create a text based interface for the application in a few hours. (Yes, there are programs you can't reasonable run without a GUI, but the point is, seperate logic from display).
• Seperate Logic from GUI code. It' bears repeating. I've seen a lot of programs where the author/previous maintainer put a small but crusial bit of logic in the GUI code. Later when re-working the GUI code stuff breaks and it's very difficult to find out where/why.
• Use Threads. In a lot of cases you can make the application feel much more responsive by keeping the display code in a seperate thread from the processing code.
• Consider your Users. When you design a GUI, remember that small things can make big differences. Consider a couple of things. First off, what is the technical level of your target audience. Second, what are you're users going to do most often. For users with little technical proficency remember that it's often preferable to use terminology that they are familiar with, even if it's not the most precise way of displaying the information. (For example, many users are confused by "export" options for programs, so you should put those options under "save as".) What your users are doing is going to effect where things go. You don't want the most common task to be 3 menus deep and at the bottom of the last tab in an obscure options window, you want it to be a big button in the main window. Likewise you don't want the most commonly clicked button to be the third down in a list of 6 or something.
• Last, spend a bit of time reading up on the psychology of colors and shapes. Certain shapes and colors tend to draw the eye and this can be useful to give users subtle visual cues and will make your application much more intuitive.

Starpacks, Tcl/Tk

[DavidNWelton]

If it's a starpack, they won't know what it is. They download one executable file that is smaller than 2 megs, and run it.

http://www.equi4.com/starkit.html

I'll second the Tcl/Tk recommendation. It's super easy to get an application up and running in no time. What's even better is that you can do most of the development on Linux if it's not an app that requires a lot of windows specific services, and then switch to windows to put the final touches on. I've even had it happen that I didn't need to change any code at all (but it's usually recommended, just to give your app that extra polish).

Win32 dialog only class

[NullProg]

I need to write a fairly simple application which will need to display data received from a serial port in a decoded (and graphical) form via a Windows GUI.

Write a simple Win32 program that uses a dialog class has its main window. Depending on how many elements your dialog needs to display, you could probably wirte this in less than two hundred lines of code. There are plenty examples on the internet to get you started. The result will be a small, tight and fast program that uses very little memory. As a bonus, your program will run on all 9x/NT versions of windows without extra dependencies, unlike the MFC/VB/C#/Wx/java frameworks other people are advising you to use.

Enjoy,

Re:TCL/TK - serial ports? sure

[DavidNWelton]

If you work around the less than ideal formatting, you can find information about dealing with serial ports here:

http://www.tcl.tk/man/tcl8.4/TclCmd/open.htm

It's part of the core system. I recently created a coin operated internet system driven entirely with Tcl/Tk. I thought I'd have to do the serial port portion in C for speed reasons, but Tcl proved plenty fast - even a scripting language operates much, much faster than someone can shove coins into a slot.

VB. Don't be fooled: VC++ is not similar

[dpbsmith]

If what you're interested in is just getting the job done, you can't beat VB... or RealBasic, which I'm partial to, since I do more of this kind of thing on the Mac, but it's not mainstream.

There are a lot of knocks on VB, but most of them are snobbery, pure and simple.

If you're interested in earning status with your developer peers, boosting your career, making your resume marketable... stay away from VB.

But if what you're interested in is just getting the job done, it's a good choice.

Postscript: do not let Microsoft's marketers fool you into thinking there's any similarity between Visual Basic and Visual C++. Visual C++ is not just Visual Basic with a different programming language component. I wish it were, or I wish they had a product like that.

VC++'s "visual" features are shallow, fragile, and paper-thin.

Re:You meant...

[heinousjay]

It may have been a Freudian slip, but I'd have to say the parent described MFC programming in an accurate fashion.

Delphi

[silverdirk]

I'll second Delphi. It uses an OO form of the Pascal language, which might be a problem for some, but I'd take pascal any day compared to basic. Also, Delphi is every bit as easy to use as VB.

I used Delphi at a co-op job for six quarters, and it just plain made me feel powerful. I could throw together a nice GUI in minutes, and then "wire up" the events to real code after getting approval from the people who would be using the program. By the time I was done, i'd have a nice professional-looking app that was only about 700K, didn't need any funny DLL files, and was made out of nice strongly-typed OO code, and took advantage of the huge selection of freeware widgets on sites like http://www.torry.net/

Delphi is the perfect language for writing fast windows apps. Its also perfect for database access, and with the right packages, can be perfect for lots of other tasks, like serial port access. (and what I mean by that is that you can go fumbling around with the Windows Serial port API, or you can get a nice I/O package for Delphi and just drag/drop some components that give you nice events to play with.)

To top it off, if you look at the assembly generated by the compiler, its really pretty good. You might say it's equivalent to -O1 on C code, and thanks to its single-pass compiler, it compiles 10x as fast, so there's basically no wait.

Re:VB not the answer

[cgreuter]

I have a bit of experience with both Tck/Tk and Visual Basic 5. Here's what I think:

Tcl/Tk is great for dashing off little graphical apps that do stuff. I once wrote a fully-functional GUI front end for "cdplayer" in 8 lines and ten minutes. It's the easiest tool I've ever used for hand-coding GUIs but you can also get GUI builders for it.

Good things:

• Cross platform, free and open-source
• Well documented in ways that don't assume you're an idiot.
• It's really, really easy to get a GUI up and running.
• It's extremely flexible. You can override nearly every aspect of a widget, add new behaviour and even write your own widgets in Tcl. I've seen WinAmp-style user interfaces in Tcl/Tk applications.
• It's simple. Most Windows-based development tools I've used have zillions of functions, classes and datatypes, far more than you could ever grok. Tcl/Tk is small enough that I could still get a sense of knowing how everything worked.
• Tcl, for all its wierdness, is an incredibly flexible language. You can write your own control structures in it and you can create multiple interpreters so that your Tcl/Tk application can provide Tcl as a scripting language while protecting the app's internals from scripts.
• It's got a really simple C API. C code can call Tcl code which calls C code which calls Tcl code and so on.
• It's interactive. You type in and evaluate expressions on the command line and even build GUI controls that way.

Bad things:

• It's ugly, at least out of the box. It's possible to make your app look nice (and maybe even Windows-native) but it requires a lot of tinkering to do.
• Tcl isn't really designed for developing large programs. (I haven't tried [incr Tcl] though--that might be better). It'll do in a pinch (and my app grew to some 13000 lines of Tcl without getting unmanageable) but lack of types and the error/catch exception mechanism became a hassle after a while.
• There were a few Windows things that I couldn't do without writing a C routine to do it and linking it in.
• No debugger. You're stuck using printf^Wputs statements.

If I were going to write a large or complex Windows app today, I'd probably write the interface in Tcl/Tk and the actual complex stuff in C.

As for Visual Basic, I didn't really use it enough to have an informed opinion. When I used it, I found that it was really easy to create a GUI but the IDE became irritating to use once I needed to write larger amounts of actual code. I also found the help reader annoying (but this was version 5--they may have improved since) and the documentation condescending.

It worked well as long as I didn't try anything too unusual. I don't think I could do Tcl/Tk trick of creating a new kind of widget by adding event handlers to a label widget in Visual Basic. But, I didn't need try it and it worked okay for what I needed to do.

Of course, given how MS radically changed the language with VB7.net and stopped supporting VB6, I don't think I'd ever use VB for any code I thought might be valuable.