D4 -- Bizarre Unpredicted Glitch
Peter N Roth
program Project3;
uses
Forms,
Unit4 in 'Unit4.pas' {Form1};
{$R *.RES}
begin
Application.Initialize;
Application.CreateForm(TForm1, Form1);
Application.Title := 'Zap'; // insert a title here
Application.Run;
end.
Compile and run, all is cool. Change the project by adding lines:
program Project3;
uses
Forms,
Unit4 in 'Unit4.pas' {Form1};
{$R *.RES}
const sTitle = 'Zap'; // introduce this line
begin
Application.Initialize;
Application.CreateForm(TForm1, Form1);
Application.Title := sTitle; // change the line to use the constant
Application.Run;
end.
Syntax check: ok. Compile: ok. Run: Nothing!
Try to change the Project|Options: project contents get wiped out, and/or
there is a problem creating the form !?
Anyone verify this as a B.U.G. ?
--
Grace + Peace | Peter N Roth | Engineering Objects Int'l
Amazon.com associate | Inprise Tool & Component Builder
http://www.inconresearch.com/eoi
Ralph Friedman (TeamB)
Peter,
modifying the DPR has always been an "at your own risk" proposition. From the
Delphi 4 help, under the "DPR" topic:
"Inside the project file
Caution: Because Delphi maintains the project file, you should not normally
need to modify it manually, and in general it is not recommended that you do
so. Most changes you could make to the project file can also be made with the
Project Manager, and doing so ensures that Delphi keeps all the project's
files synchronized."
--
Regards
Ralph (TeamB)
--
Peter N Roth wrote in message <7bkug9$34...@forums.borland.com>...
|Start a new project. View the project source code:
|
<deletia>
Peter N Roth
>modifying the DPR has always been an "at your own risk" proposition. From
the
>Delphi 4 help, under the "DPR" topic:
aaaaaaaaaaghkk!
Does the 'Make a console app' turn that "management" off?
This is the first time since TP2 that modifying the main program
has caused any problems, for me anyway. I've learned to avoid
modifying the IDEs mgt of Forms, but this is a _shock_ !
In the help files, or anywhere, is there something says what is
being "managed" ?
Bruce Roberts
>
>
>Caution: Because Delphi maintains the project file, you should not normally
>need to modify it manually, and in general it is not recommended that you
do
>so. Most changes you could make to the project file can also be made with
the
>Project Manager, and doing so ensures that Delphi keeps all the project's
>files synchronized."
This is one of the silliest things I've read. In another part of the help an
example is given of modifying the project file to display a splash screen.
Also, Delphi also manages unit files that contain forms, following the above
logic, we shouldn't manually change those files either.<g>
Ralph Friedman (TeamB)
my perception is that the warning is a (necessary) CYA statement. It takes
some fiddling, but you can usually do it in a way that doesn't "offend" the
IDE's parser.
|Does the 'Make a console app' turn that "management" off?
|
It probably knows what it is doing. The same as with a Library unit.
--
Regards
Ralph (TeamB)
--
Peter N Roth wrote in message <7bmrq3$58...@forums.borland.com>...
|Ralph Friedman (TeamB) wrote in message <7bl6kb$3l...@forums.borland.com>...
|
Ralph Friedman (TeamB)
something like:
unit Unit1;
interface
uses
Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs,
StdCtrls;
type
TForm1 = class(TForm)
Label1: TLabel;
procedure FormShow(Sender: TObject);
private
public
constructor Create(AOwner: TComponent); override;
end;
var
Form1: TForm1;
implementation
{$R *.DFM}
uses
Splash;
constructor TForm1.Create(AOwner: TComponent);
begin
FrmSplash := TFrmSplash.Create(Application);
FrmSplash.Show;
FrmSplash.Update;
inherited Create(AOwner);
end;
procedure TForm1.FormShow(Sender: TObject);
var
count: integer;
begin
for count := 1 to 10000 do
begin
Label1.Caption := IntToStr(count);
Label1.Update;
end;
FrmSplash.Release;
end;
end.
--
Regards
Ralph (TeamB)
--
Ross C. Williams wrote in message <36df51a3...@forums.inprise.com>...
|Ralph -
|
|How do you display a splash screen without modifying the dpr file?
|
Ralph Friedman (TeamB)
afa using the dpr in general and the splash screen in particular, see my
replies to Peter and Ross. AFA the normal units go, modifying anything above
the "private" declaration will usually get you in trouble.
--
Regards
Ralph (TeamB)
--
Bruce Roberts wrote in message <7bnoes$5j...@forums.borland.com>...
Bruce Roberts
Personally, I don't really like your splash screen work around. To me, it
makes more sense to put it into the project file. In any case, what about
login forms?
> . . . AFA the normal units go, modifying anything above
>the "private" declaration will usually get you in trouble.
And that is documented. So why didn't Inprise document the project file in
the same way? I.E. don't play directly with the uses clause or any of the
Application.CreateForm statements. After all, the project file is the "main
program" and there are a number of projects I've worked on that require
either a fair amount of processing before displaying a form and/or don't
really have a single "main form".
Peter N Roth
>my perception is that the warning is a (necessary) CYA statement. It takes
>some fiddling, but you can usually do it in a way that doesn't "offend" the
>IDE's parser.
I really would like to know what is going on there.
>|Does the 'Make a console app' turn that "management" off?
>It probably knows what it is doing.
BWA HAW HAW HAW
sorry, couldn't help it
Ralph Friedman (TeamB)
|Personally, I don't really like your splash screen work around. To me, it
|makes more sense to put it into the project file.
That personal choice and fair.
|In any case, what about
|login forms?
Same technique as Splash raise Abort if login fails.
|And that is documented. So why didn't Inprise document the project file in
|the same way? I.E. don't play directly with the uses clause or any of the
|Application.CreateForm statements. After all, the project file is the "main
|program" and there are a number of projects I've worked on that require
|either a fair amount of processing before displaying a form and/or don't
|really have a single "main form".
IMO, the warning in the help file says what needs to be said.
FWIW, I do have projects that modify the dpr. I accept that it may have to be
changed when the version changes. Hasn't happened yet. Peter just happened
upon something that caused trouble. If you have code that is working, I would
neither change it nor be too concerned about it.
--
Regards
Ralph (TeamB)
--
Bruce Roberts wrote in message <7bp3i9$72...@forums.borland.com>...
Ralph Friedman (TeamB)
he who controls the code...<g>
--
Regards
Ralph (TeamB)
--
Peter N Roth wrote in message <7bp67u$72...@forums.borland.com>...
Brian Lindahl
However, the Abort in the create does not stop the rest of the DPR from
executing, until it hits application.run then it stops. How can I get it to
skip auto-creating the rest of the forms and data modules if the abort
happens? The problem is that some of the other forms & DMs rely on the login
succeeding. I have been told that I should not autocreate the sensitive
stuff and create it myself after the login succeeds. Is this the only way?
I'd much rather have Delphi do it for me - it's cleaner and more obvious to
other developers.
brian
Ralph Friedman (TeamB) wrote in message <7bp87g$72...@forums.borland.com>...
Ralph Friedman (TeamB)
Login;
constructor TFrmLoginMain.Create(AOwner: TComponent);
var
return: integer;
begin
// FrmLogin should be in the "Available" list
//
FrmLogin := TFrmLogin.Create(Application);
return := FrmLogin.ShowModal;
FrmLogin.Release;
if return = mrOk then
inherited Create(AOwner)
else
Abort;
end;
--
Regards
Ralph (TeamB)
--
Brian Lindahl wrote in message <7c142k$er...@forums.borland.com>...