Search Members Help

» Welcome Guest
[ Log In :: Register ]

 

[ Track This Topic :: Email This Topic :: Print this topic ]

reply to topic new topic new poll
Topic: main window - ZZZZZZ.... (coma)< Next Oldest | Next Newest >
 Post Number: 1
stellar Search for posts by this member.

Avatar



Group: Members
Posts: 1
Joined: May 2010
PostIcon Posted on: May 07 2010,17:04  Skip to the next post in this topic. Ignore posts   QUOTE

Excellent product.  I've very much enjoyed using UltraISO, and found it very useful.  I believe it's generally very well written.  However, nonetheless, I have an issue and complaint.  This is short of what I'd call 'a bug', which is why I have not posted this in the 'bugs' forum.  But it's a quirk of the program that is irritating, nonetheless.

In compressing a large ISO file, which takes some time, I've noticed that with the main window maximized (to full screen), it *cannot* be minimized while the program is busy creating the ISZ file.  The main window remains firmly locked in place and unresponsive.

I believe that no program should behave that way.  A program's main window should *always* respond and minimize, when requested to do so, even if one of its threads is very busy.  I've used other Windows programs which can be extremely busy with similar (disk intensive) tasks, yet the main interface remains nicely responsive to window placement requests.  (NewsRover, for example, is more polite.  It can be busy rebuilding the database, yet it still quickly and obediently responds to a click on the upper right minimize button.)

The basic philosophy is: no thread should leave other threads (especially parent threads) crippled, and particularly not do that when they display windows on the screen.  A sub-window should NOT dominate the parent window, in other words.  But that breach of good programming etiquette is effectively what's going on in UltraISO.  A child thread is dominating the parent.

It's a matter of having such threads remain 'humble' and aware of window placement requests, to permit a response to the request.  A simple check, every so many loops, in the busy thread - has a window placement request been received? - would suffice.

In my opinion, no program should ever leave itself completely covering the screen and ignore user request.  I should be able to do something else, while the program is busy.  But given that lack of response - to anything but a cancel or stop - that's made more difficult.

So could someone please take a look at the code, and remedy that?  Because in my opinion, it's a bit of ugly.

Otherwise, I've had no problems with UltraISO at all, and I'm quite impressed.  Applauding, in fact.  Well done.  Regards, Rod
Offline
Top of Page Profile Contact Info 
 Post Number: 2
klauzser Search for posts by this member.

Avatar



Group: Members
Posts: 24
Joined: May 2012
PostIcon Posted on: May 30 2012,22:06 Skip to the previous post in this topic.  Ignore posts   QUOTE

I cannot agree more. I've been using their product like everyday and it is great.
Offline
Top of Page Profile Contact Info 
1 replies since May 07 2010,17:04 < Next Oldest | Next Newest >

[ Track This Topic :: Email This Topic :: Print this topic ]


 
reply to topic new topic new poll

» Quick Reply main window - ZZZZZZ.... (coma)
iB Code Buttons
You are posting as:

Do you wish to enable your signature for this post?
Do you wish to enable emoticons for this post?
Track this topic
View All Emoticons
View iB Code