views:

124

answers:

3

i've been trying to get some modeless forms in my application to appear on the taskbar - taking advantage of the new useful taskbar in Windows 7.

There's are many issues with the VCL that need to be undone before a form can exist on the taskbar.

But the final issue is that minimizing the form that the VCL has designated the main form causes all windows in the application to vanish.

Ten years ago, Peter Below (TeamB) documented these problems, and attempts to work around them. But there are some issues that cannot be solved. The issues run so deep within the VCL itself, that it's effectively impossible to make Delphi applications behave properly.

It all stems from the fact that the button you see on the toolbar does not represent the application's window; it represents the TApplications window, which is hidden and never seen. And then there is the application's MainForm, which is then imbued with special abilities where if it is minimized then it instructs the application to hide itself.

It seems to me that if i can do

Application.MainForm := nil;

then all these bugs would go away. The application can have its hidden window, and in the meantime i'll override every other form in the application, including my main form, with:

procedure TForm2.CreateParams(var params: TCreateParams ); 
begin 
   inherited CreateParams(params); 
   params.ExStyle := params.ExStyle or WS_EX_APPWINDOW; 
end; 

But in Delphi the Application.MainForm property is read-only.

How can i not have a MainForm in Delphi?

See also

+6  A: 

You can't, especially in Delphi 5.

Your quote concerning the TApplication window being the one seen on the task bar hasn't been true for several Delphi versions now (I believe D2007 changed it).

Because you're using Delphi 5, you're using an outdated copy of Delphi; current versions have almost none of the things you're writing about any longer. I'd suggest you upgrade to a later version of Delphi (D5 is extremely old); Delphi 2007 if you need to avoid Unicode, Delphi XE if you can use (or don't mind having) Unicode support in the VCL and RTL.

The things you're describing are not bugs, BTW. They were intentional design decisions made at the time Delphi 1 was being designed, and through Delphi 7 worked fine with the versions of Windows that were available. Changes in later versions of Windows (XP/Vista/Win7 and the equivalent Server versions) made changes in that architecture necessary, and they were made as Delphi progressed along with Windows. Because you've chosen not to progress with your version of Delphi to keep it more recent doesn't make the things you write about magically become bugs. :-)

Ken White
i would love to spent a few thousand dollars every year or two - but its not going to happen. We've mostly switched to free Visual Studio. i would love Borland to release a free version of Delphi. But accepted answer *you can't*, since it is a valid (and i assume correct) answer.
Ian Boyd
Ian: It wouldn't have been a few thousand dollars every year if you'd upgraded (D5 days); the Pro version upgrade cost was around $300 then. The current Pro version has gone up to around $400, but Software Assurance (around the same price) gives you free upgrades for 12 months at a time. A free version would be great, if Embarcadero had the billions in revenue from other product lines to support it. Since they're not MS, they don't.
Ken White
There is also the non-zero cost in converting and testing applications in the new delphi version (e.g. changes with TThread and synchronize, new components, dsgnintf.pas/dsgnintf.dcu/DesignInterface/ DesignerInterfaces/DesigntimeInterfaces, Types/Variants, string/AnsiString/WideString/UnicodeString)
Ian Boyd
That non-zero cost in converting and testing was much less than the non-zero cost of switching your entire development from one language/IDE (Delphi) to an entirely new one (VS/whatever language you chose). :-)
Ken White
Obviously we didn't switch everything (only new projects) since i'm still asking about Delphi 5.
Ian Boyd
I figured that, but you still had the non-zero cost of switching IDE/language for new projects, right?
Ken White
Since you're talking about D5, what was VS version on D5 release? Mayber 5 or 6. Since VS.NET changed all the things, it means that an equivalent switch on MS land would cost more since it'll (or maybe almost) be a complete rewrite of the application. From this POV, a switch between Delphi versions would be a breeze in cost terms.
Fabricio Araujo
@Ken White, @Fabricia: i don't disagree with you. While Delphi 6 was a god-awful mess, Delphi 7 is great - and BorImpEmbargadero has been having a mess trying to get it's Visual Studio clone of Delphi working... But i wish we would have kept upgrading. But it's not up to me. And i can't really justify to anyone why their next update will take so long and (oops) have bugs. And i can't force everyone else to upgrade because i want to. And the *free* price tag of VS is something i can't really argue with - considering there's been n sub-par versions of Delphi since DFDN.
Ian Boyd
A: 

You can put your modeless forms in a dll, then they act pretty much on their own. (If you do not use the Application instance of the dll while creating them (Application.CreateForm) then Application.Mainform is nil in the dll).

Of course this might not be feasible depending on what the forms might need to do.

Sertac Akyuz
There are terrible hazzards associated with exposing a class from a dll - you cannot add or remove any private members or methods.
Ian Boyd
I did not quite understand what you mean by adding private members, but of course this kind of design would impose limitations. As I said in the last paragraph it might just not be feasible. BTW, I have some old projects (D3) with only *one* line of code in the executable: `ShowFormInDll;`. Then, 'Application.MainForm' is effectively nil for that project.
Sertac Akyuz
It's the hazzards of having a class in a DLL. Anyone calling methods on an object exposed from a dll have to know the declaration of the form in the dll. This is so that when it calls a method it calls the proper offet in the Virtual Method Table (VMT). If your form adds a private member (e.g. an integer, which is four bytes), anyone calling that form will now crash, since they will four-bytes off when looking at,what they think, is the VMT. The application and dll have to always be compiled together. If you don't, you will get crashes. These issues are the reason COM was invented.
Ian Boyd
@Ian - Ok, then put your forms in a COM dll. <g> Seriously though, I never thought about operating directly on a dll object from the application, thanks for explaining.
Sertac Akyuz
@Sertac Akyuz: Ugh, and now have to register COM classes every time i want to ship a version? Delphi's single-executable is a ***huge*** feature - which unfortunately Microsoft doesn't share.
Ian Boyd
+1  A: 

You cannot run a GUI project without a MainForm assigned. The main message loop will exit immediately without one. However, that does not mean that the MainForm has to run your UI. You can use a blank hidden TForm as the assigned MainForm, and then have it instantiate your real MainForm as a secondary TForm.

Remy Lebeau - TeamB