Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 10 of 16 total
Thread CopyTable Problem
Thu, Feb 16 2006 5:19 PMPermanent Link

Ted K
Using DBISAM C/S 3.30 Win XP

Some of my clients are having a problem with my application which uses the CopyTable method on a large table (200 megs). After approx 4-5 minutes the
screen "greys out" and when they try to close the application the "not responding" message appears.  The weird thing is that when they check the table to be copied to in
dbsys, it's there!  Any ideas??
Fri, Feb 17 2006 4:01 AMPermanent Link

"Jose Eduardo Helminsky"
Ted

My suggestion. Check the source of DBSys and you will find what is different
from your code.

Eduardo

Fri, Feb 17 2006 4:32 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

Ted


I had a user where he'd get the app greyed out after bringing another app to the foreground - eventually it turned out to be a screensaver/password messing things up.

Roy Lambert
Fri, Feb 17 2006 10:43 AMPermanent Link

Ted K
Thanks, but I already have done that and the only difference I could see was that in DBSYS a procedure is assigned to the OnCopyProgress event handler of the
SaveTableDlg component.  I assumed this was only necessary for the progress gauge in dbsys, which I did not use.  My question is: Why can the copyTable method not
be used on it's own, or is there something else required for large tables?

"Jose Eduardo Helminsky" <contato@hpro.com.br> wrote:

Ted

My suggestion. Check the source of DBSys and you will find what is different
from your code.

Eduardo

Fri, Feb 17 2006 11:47 AMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Ted,

<< Some of my clients are having a problem with my application which uses
the CopyTable method on a large table (200 megs). After approx 4-5 minutes
the screen "greys out" and when they try to close the application the "not
responding" message appears.  The weird thing is that when they check the
table to be copied to in dbsys, it's there!  Any ideas?? >>

Is the destination table present ?  This sounds like a screen redraw issue.
What happens if you hook up an OnCopyProgress event and simply call
Application.ProcessMessages inside of it ?  That should fix any screen
redraw issues.

--
Tim Young
Elevate Software
www.elevatesoft.com

Fri, Feb 17 2006 12:32 PMPermanent Link

Bernd Kuhlmann
Ted,

> Using DBISAM C/S 3.30 Win XP
>
> Some of my clients are having a problem with my application which uses the
> CopyTable method on a large table (200 megs). After approx 4-5 minutes the
> screen "greys out" and when they try to close the application the "not
> responding" message appears.  The weird thing is that when they check the
> table to be copied to in
> dbsys, it's there!  Any ideas??

Microsoft has changed the behaviour in Windows XP.
From
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winui/windowsuserinterface/windowing/messagesandmessagequeues/aboutmessagesandmessagequeues.asp
(or search in google for: windows xp not responding redraw)
---
Microsoft Windows XP: If a top-level window stops responding to messages for
more than several seconds, the system considers the window to be not
responding. In this case, the system hides the window and replaces it with
a ghost window that has the same Z order, location, size, and visual
attributes. This allows the user to move it, resize it, or even close the
application. However, these are the only actions available because the
application is actually not responding. When in the debugger mode, the
system does not generate a ghost window.
---

So a code fragment like this:

begin
 mytable.first;
 while not mytable.eof do
 begin
   doSomething;
   mytable.next;
   label.caption:=counter;
   update;// this doesn't really help under windows xp
 end;
 ShowMessage('Done');
end;

which runs fine under windows 2000 shows the behaviour you describe under
windows XP.
The only solutions i am aware of are
1. use application.processmessages (and make sure that all buttons are
disabled)
2. use a seperate thread

Bernd Kuhlmann

PS: to make this even worse the ShowMessage window is sometimes "shown"
behind the current window. Sometimes you can bring the ShowMessage window
to front with Alt-Tab.





Fri, Feb 17 2006 1:06 PMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

Bernd


Bloody hell!

Does that mean that if I have any loops which might take a while I have to use application.processmessages and slow it down!?

Roy Lambert
Fri, Feb 17 2006 1:16 PMPermanent Link

"J. Lee"
Yes, or use threads. I always place user feedback just as important as
raw application speed.

~J. Lee

Roy Lambert wrote:
> Bernd
>
>
> Bloody hell!
>
> Does that mean that if I have any loops which might take a while I have to use application.processmessages and slow it down!?
>
> Roy Lambert
>
Fri, Feb 17 2006 2:06 PMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

J.


(nice name Smiley

From the link

"If a top-level window stops responding to messages for more than several seconds, the system considers the window to be not responding."

I agree user feedback is of high importance but several seconds is just madness. Some loops its just not worth giving feedback - I normally just change the cursor - and in some application.processmessage is positively dangerous.

Roy Lambert
Fri, Feb 17 2006 2:31 PMPermanent Link

Sean McCall
Finally I understand what I have been seeing! We have
maintenance functions launch from a window with progress
bars that are updated with Application.ProcessMessages
between processing tables... some operations on very large
tables take a while between progress updates and calls to
Application.ProcessMessages.

Once XP has decided that a window is not responding (usually
because the user makes another window the top window), the
progress bars no longer update even when
Application.ProcessMessages is called. The screen will not
return to normal operation until all the processing is
completed and presumeably the mouse/keyboard input is fully
handled again. The problem is that user thinks the program
is locked... the addition in the caption of "(not
responding)" on XP's fake window just re-enforces this
notion. We warn the users before starting that on XP the
screen may stop updating. I wish there were a way to turn
off this "feature" or that Microsoft had at the sense to
change "(not responding)" to something less alarmist like
'(working)' or '(processing)'. Even better, the could have
added a moving icon or animated background color to the
caption to show it is working.

Sean

Roy Lambert wrote:
> J.
>
>
> (nice name Smiley
>
> From the link
>
> "If a top-level window stops responding to messages for more than several seconds, the system considers the window to be not responding."
>
> I agree user feedback is of high importance but several seconds is just madness. Some loops its just not worth giving feedback - I normally just change the cursor - and in some application.processmessage is positively dangerous.
>
> Roy Lambert
>
Page 1 of 2Next Page »
Jump to Page:  1 2
Image