Correct Interface for Busy Application in NT 4.0?

[RalphTheCow]

I often run programs on an NT machine that take a while to execute. What is the proper interface for a program in this busy state?

Usually I'll switch to something else, then I'll occasionally select the icon of the busy program on the taskbar. If it is still busy, it does nothing; when it's done, it will display. In between I sometimes look at the Task Manager and the program will show Not Responding. I was just wondering if this is the way it is supposed to work. If you leave the screen up, it will show an hourglass as expected.

 

[NogginBoink]

This is expected behavior for an application that is not processing incoming messages.

If the app is busy, and it's not calling GetMessage(), messages for the application, such as "draw your window in the foreground," won't be accepted by the app and the app's window won't draw.

If you know the app is busy doing stuff, it's a minor annoyance. The developer should have written a multithreaded app and had one thread do the message loop and the other thread do the busy work.

In short, if this is the only symptoms of badness, I think you're okay.

 

[RalphTheCow]

Thanks NogginBoink. I know that was a picky point, just curiosity more than anything else.

But, I should have mentioned that one of the programs that does this is Excel 97. Wouldn't that be multithreaded? i.e. be about as complete as any software out there?

 

[Superwormy]

Excel is a POS!!!

And I doubt as if it would be multi-threaded, I can't find docs anywhere on whether it is or is not :-(

But it's a small business app so I highly doubt its multithreaded, only server and workstation software is usually multithreaded.

 

[NogginBoink]

You can determine the number of threads in an app from task manager in NT/W2K/XP. Show the column "thread count." Note that if only one thread is running, it still might be possible that the app is multithreaded, but you haven't done whatever it takes for the app to spawn additional threads.

As for only high-end software being multithreaded, that's not necessarily true. It's an okay generalization, but it is a generalization. Many developers advocate writing multithreaded apps if your app does time-consuming busy work: one thread to do the work and one to handle the UI, for precisely the reasons stated in this thread.

 

[RalphTheCow]

Wow, almost every program has more than 1 thread, Excel just sitting idle has 10.

I ran something in Excel that took a few seconds, it stayed at 10 but got some CPU time.

This is interesting. I guess none of the threads handle the message loop?