Fog Creek Software
Discussion Board




vb and UI

hi,

I've been reading through this web site, and came to the trivial conclusion that Joel prefers VB for UI programming.

For the most part, I agree with everything he said, but I do have one problem. People have gotten used to GUI that stays responsive. That means, to my knowledge, that one thread runs the UI and the real work is done on other threads. VB, as far as I know, doesn't support multiple threads.

So how do you do decent GUI in VB that stays responsive? or do you just live with it?

Or Peles
Tuesday, December 25, 2001

Application responsiveness is usually not about allowing the user to issue commands while other commands are running. It's about providing immediate feedback - always letting the user know what is going on. Hourglasses, progress dialogs and that kind of stuff.

Even when I use languages where I can run application logic in separate threads, I won't do it, because I like to keep things simple, and multithreaded applications aren't.

Johannes Bjerregaard
Wednesday, December 26, 2001

Johannes Bjerregaard wrote:
"Even when I use languages where I can run application logic in separate threads, I won't do it, because I like to keep things simple, and multi threaded applications aren't."

While you are right that far too many developers overcomplicate their coding just for the fun of it, there are several examples where threading greatly improves the user waiting experience.  Imagine not being able to do anything useful until:

- your Browser has loaded the complete web page or zip file.

- your email application has downloaded all messages.

- your image browser has loaded all images.

- CityDesk has uploaded all articles.

Or Peles wrote:
"So how do you do decent GUI in VB that stays responsive? or do you just live with it?"

The answer is Delphi,
amen.

Jan Derk
Thursday, December 27, 2001

Your exceptions are all valid to some extent. I especially agree with your solution.

I've been wondering why a whole lot of Delphi guys seem to hang out on this site. I remember when I was a C++ programmer, and I liked to spend my time reading about how to exploit and work around problems with exotic language features like const functions, templates, overloaded operators and the lack of events or delegates.

My theory is that it's because Objectpascal don't have a lot of these exotic problems, and you gotta move on to a another level to keep yourself entertained.

Or maybe I'm wrong and the Delphi guys are just more noisy about their language preference.

Johannes Bjerregaard
Thursday, December 27, 2001

Jan, also remember that your examples can be solved with non-blocking socket I/O as well as multitheading.

IMHO threading should only be used for exploiting multiprocessor systems; I find non-blocking I/O systems are generally easier to design & debug since all application state is explicit.

Dan Maas
Saturday, December 29, 2001

Dan Maas wrote:
"Jan, also remember that your examples can be solved with non-blocking socket I/O as well as multitheading."

You are right for the Internet examples (not for the image example). Asynchronous sockets prevents having to use threads. However, personally I don't find keeping track of all events in asynchronous sockets too much fun either. I prefer blocking sockets with threads as it IMHO creates clearer code. But I agree that this is a personal matter.

What I don't understand is the fuzz about threads being complex and evil. In Delphi it takes just a few lines of code to use them.

Jan Derk
Saturday, December 29, 2001

>> VB, as far as I know, doesn't support multiple threads.

VB's support of threads is not excellent, by any standards. But it does support them (though it is especially difficult when coding an MDI app). The Coffee example on the VB CDs will introduce you to some of the basics.

Matthew Wills
Tuesday, January 01, 2002

Although someone is sure to chime in with a 'VB.NET is not VB' followup, the threading support in VB.NET is quite good.

Dave Rothgery
Wednesday, January 02, 2002

Gee, are we not all forgetting that the UI part of code in C and VB is not really going to perform much different?. In other words you are spending about 80 or more % of your time running the windows API. That windows api is going to run the same speed regardless if you use C, or vb.

Drawing a text box in VB is no slower than drawing a text box in C (assuming you use the API to do this..). C++ will allow you to send more requests to the API in a given amount of time...but it is the drawing time that slows us down. That drawing time is exactly the same in both C and VB.

Thus, the general feel, and performance of CityDesk (for example!) is just fine. C++ would not helped this product at all. (the only exception here is that incredulity slow spell checker...which Joel’s folks did not write...). On my pIII600, that spell checker cannot remotely keep up to me.

The amount of time that an application spends in its own code is actually quite small. In addition VB does have now have a TRUE compiler, and this speeds up the code to the point where the gab between VB and C becomes even less noticeable.

Albert D. Kallal
Sunday, January 06, 2002

*  Recent Topics

*  Fog Creek Home