Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Forms and Windows behavior in Delphi 7

960 views
Skip to first unread message

Manolis

unread,
Dec 5, 2005, 9:06:40 AM12/5/05
to

I have a large project built in Delphi 7 with 16 packages and hundreds of forms. My application consists of a main window and all the other forms have the form style property set to StayOnTop.
After installing and using the program to a lot of users I faced some strange problems regarding the windows and forms behavior (Most of them are complaints from the end users). These are:
1. Many times after pressing the Alt+Tab keys it doesn't work. It doesn't switch to other applications. Working in the previous version of my application built in MsAccess never had this problem.
2. A lot of times when a message box is displayed is not actually shown on the monitor and the application seems to be halted. You have to press the enter key which causes the OK button of the invisible message box window in order to dissapear and make the application enabled again.
3. Some times when I run a stored procedure which needs some time to run all the windows of the application dissapear, and only the main window is present. After minimizing the main application window I find the other windows which should stay on top of the main window to be in the back of it. Bringing them to front again and preesing on the main app.window they dissapear again. It seems that they had lost theit stayontop form property. I have to close and open the propgram again in order to have the proper windows behavior.
4. While working the program only one tab of it, appears on the windows task bar. However some times 2 tabs are dispayed the second has a caption of a form which is opened in the main application. Trying to close it by right clicking and close, causes the closing of the whole application.

Has anyone experienced these problems??

Regards,
Manolis Perrakis

ironfede

unread,
Dec 5, 2005, 11:24:03 AM12/5/05
to
>> 2. A lot of times when a message box is displayed is not actually shown
>> on the monitor and the application seems to be >halted. You have to press
>> the enter key which causes the OK button of the invisible message box
>> window in order to >dissapear and make the application enabled again.

Hi,
I've experienced problem 2) (Delphi 7, Windows XP pro);
A little workaround may be to activate the form wich should be "deactivated"
by the modal window just before the call that makes appear this modal
window.
This wrong behaviour appears when there is a delay between the call to the
function that invokes the modal window and its effective execution ( in my
app I was getting some data from the web to be displayed in a modal window).
I've not investigated this problem but it could be related to threads
synchronization in the update of GUI ... I don't know.

Best regards,
Federico Blaseotto

Russ Holcomb

unread,
Dec 5, 2005, 11:34:31 AM12/5/05
to
For 2 you might try mb_taskmodal in the messagebox.

Russ

"Manolis" <manolo_...@yahoo.gr> wrote in message
news:43945780$1...@newsgroups.borland.com...

Peter Below (TeamB)

unread,
Dec 5, 2005, 2:42:45 PM12/5/05
to
In article <43945780$1...@newsgroups.borland.com>, Manolis wrote:

> I have a large project built in Delphi 7 with 16 packages and hundreds
> of forms. My application consists of a main window and all the other
> forms have the form style property set to StayOnTop.

Why are you doing that? StayonTop forms should be used very sparingly. If
you want to keep your secondary forms on top of the main form even if focus
is set to the main form do it this way:

Override the CreateParams method of the secondary forms like this:

procedure TForm2.CreateParams(Var params: TCreateParams);
begin
inherited CreateParams( params );
params.WndParent := Application.Mainform.handle;
end;

This is not completely failsafe, you have to avoid changes to the main forms
styles (border, bordericon, formstyle) that would force the VCL to recreate
the window handle. If this ever happens the Z-order link between the forms would
be lost. You could guard against this by overriding the main forms CreateWnd
method. Call the inherited method first and then iterate over the list of open
forms in Screen.Forms (skipping the main form, of course) and call their
RecreateWnd method to force them to recreate their own window handle as well.
That calls CreateParams again and reestablishes the link.

This will take care of your problems 1 and 2. 3 is an XP-specific problem
caused by a system feature (some would call it a bug, but it is by design <g>)
called window ghosting. It strikes when your main thread does not process
messages for a few seconds. The OS then thinks your app is hung, hides its
windows (all of them) and creates a fake of the main window so the user has
something to play with (he can move it around and minimize it, for example,
to get it out of the way).

The proper way to deal with this is not to block your main thread for more
than a few hundred milliseconds. But that can require a significant redesign,
since you need to move time-intensive operations into secondary threads.
The usual (lazy) way is to use DisableProcessWindowsGhosting, search the
newsgroup archives for it to find examples of use and some background
info on the problems.

Your problem 4 is something i have not seen mentioned before on these groups.
It may be connected to 3.


--
Peter Below (TeamB)
Use the newsgroup archives :
http://www.mers.com/searchsite.html
http://www.tamaracka.com/search.htm
http://groups.google.com
http://www.prolix.be


Manolis

unread,
Dec 6, 2005, 1:24:59 AM12/6/05
to

Hi Peter,
Thank for the response. However the solution you described regarding the stayontop behavior has a problem.
I've overriden the CreateParams method and entered the code you told me. The windows stay on top of the main form.
If I use the desktop icon on the task bar in order to display the desktop and have an opened form in my application, when I return to my application by using the Alt+Tab or the tab on the taskbar the main window is not displayed. Only the other forms are displayed. I must close all the forms in which I used the code you told me in order to display the main application window. I think is the same issue you describe in your response.

I tried to use the recreateWnd but I'm not sure how to use it.
How do I the RecreateWnd method for each form?
The Code I wrote was:
procedure TFrmMainForm.CreateWnd;
Var
I:Integer;
begin
inherited CreateWnd();
for I := 0 to Screen.FormCount do // Iterate
begin
if Screen.Forms[i].Name<>'FrmMainForm' then
begin
//(Application.FindComponent(Screen.Forms[i].Name ) as TForm).
??????????????????????
ReCreateWnd;
end;

end; // for
end;

Can you please tell me how to proper write this code??
Regards,
Manolis

Manolis

unread,
Dec 6, 2005, 1:49:03 AM12/6/05
to

The behavior of the main form which is hided if I use the desktop icon can be restored if I right click on the task bar on the application tab and choose restore. How can I avoid this??

Regards,
Manolis

Peter Below (TeamB)

unread,
Dec 6, 2005, 2:04:32 PM12/6/05
to
In article <4395426f$1...@newsgroups.borland.com>, Manolis wrote:
>
> The behavior of the main form which is hided if I use
> the desktop icon can be restored if I right click on
> the task bar on the application tab and choose restore.
> How can I avoid this??

The show desktop function seems to actually minimize your application
in your case, but it does not get properly restored. You can fix that
by adding a handler to the Application.OnActivate event (i used a
TApplicationEvents object in the main form for the test).

procedure TForm1.ApplicationEvents1Activate(Sender: TObject);
begin
if IsIconic(Application.handle) then
Application.restore;
end;

Manolis

unread,
Dec 7, 2005, 1:23:58 AM12/7/05
to

Some other strange effects occured. Tried to minimize application by clicking on the tab on the task bar, some times work and some time doesn't. Some time it minimizes only the main window and leaves the other application windows opened in front of the other current application. Trying also to minimize ( by clicking on the tab on the task bar)it seems like a window is minimized (like other application do) and another invible window is maximized.
Also many times when rting to switch to other applications these are displayed in front of the main application window but behind the other application forms.
Any suggestions?

Regards,
Manolis


"Peter Below (TeamB)" <10011...@compuXXserve.com> wrote:

>In article <4395426f$1...@newsgroups.borland.com>, Manolis wrote:
>>
>> The behavior of the main form which is hided if I use
>> the desktop icon can be restored if I right click on
>> the task bar on the application tab and choose restore.
>> How can I avoid this??
>
>The show desktop function seems to actually minimize your application
>in your case, but it does not get properly restored. You can fix that

>by adding a handler to the Application.OnActivate event (i used a r

Peter Below (TeamB)

unread,
Dec 7, 2005, 2:19:38 PM12/7/05
to
In article <43968e0e$1...@newsgroups.borland.com>, Manolis wrote:
> Some other strange effects occured. Tried to minimize application
> by clicking on the tab on the task bar, some times work and some
> time doesn't. Some time it minimizes only the main window and
> leaves the other application windows opened in front of the other
> current application. Trying also to minimize ( by clicking on the
> tab on the task bar)it seems like a window is minimized (like other
> application do) and another invible window is maximized.

When the application is minimized the main form gets hidden. That should
also hide all windows it owns on the API level. If that does not happen
XP is worse than i though at handling Z-order relationships between windows.

Application has OnMinimize and OnRestore events you could use to manually
hide and show your secondary forms, but that should ne necessary. I've no
idea why you have problems here, sorry. And i'm running out of time today...

0 new messages