Re: Storing data in the application/exe file

No..form is not modal. It doesnt have anything to do with first
one(test.exe). When you click save button on the form of test.exe ,it
should create runtime.exe ..Now about data..heres little example
What if you put all label controls on form assigning values
to label control. like if you build customer dataentry form but using
label control instead of using TEdit. and assign values designtime.
Like Label_customername.caption="Maarten Wiltink";
and then make exe. Now when you make exe you dont have to worry from
where data is coming because its already hardcoded in exe before
createing exe..Makes sense?

I appriciate you help...Thank you

Maarten Wiltink wrote:
"BB" <shmilyca@xxxxxxxxx> wrote in message
news:1149108367.470410.206520@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Project groups are just a way to have several projects open in the IDE
at the same time. A single project compiles to a single executable, but
this has nothing to do with the forms in your project. They are the
next layer down.

So you mean..if ptoject group have ..say two three projects..they cant
talk to each other being in group?

No. Look at it like this: projects don't _know_ if you have a project
group that contains them or not. Or several. If a project is not in
a group, other projects are in no way special. If it is... they still
aren't.


You have to create each form yourself when you need it. You have to
keep track of them if you want to re-use them.

What do you mean keep track?Can you please explain it?

If you let Delphi have its way, one instance of each form in the project
is created at startup, and that global variable in the form unit will
point to it.

If you do not autocreate forms, nothing stops working, but you do have
to create each form you want to use. Once, normally. If on closing a
secondary form you again let Delphi have its way, the form will be
hidden and not freed. If you keep a reference to it then next time you
want it, you can make it visible again. If you simply forget about it,
you have a memory leak and need to create another instance next time
you need that form.

For single-instance forms, that global variable in the declaring unit
is not a bad way of keeping track of instances. If it's nil, you don't
have a form yet (or not any more). When you create a (the) form, keep
a reference in the variable. When you _hide_ the form, leave the
variable. When you _destroy_ the form, clear the variable. When you
need the form, you know if you have one ready for use or need to
create it. Keeping track of your forms.

Another useage mode is common with property forms. There may be
several forms open at the same time, all displaying the properties
of distinct objects. If you want to display an object and a form
already exists that does, it's neater to pull that to the foreground
than to create another one. But you can no longer make do with a single
variable, you need a list. Other than that, nothing much changes: when
you create a new form, add it to the list; when you free it, remove it.
The global variable that Delphi puts in each form unit is essentially
a list that can have either zero or one elements.


Let me explain it
better what i was trying to acheive..Say user is running my app..we
call it Test.exe. This test.exe have more than one forms.Now when user
goto perticular form in my app ..say customer data entry..after he is
done with entry when he clicks save..I want to create an exe (we call
this runtime.exe) that when you run runtime.exe, it will just display
you customer data entry form with data. now if he copies this
runtime.exe and run over another computer that even dont have test.exe
he should be able to run it.
Know what I mean?

Yes, I get it. It's not immediately problematic, but it does beg a few
questions.

First, should the second form be modal with respect to the first? This
is much harder to do if they are in different executables.

Second, where does the data entry form put its data? If the main form
may or may not be there, that's one place it can't go. Not to mention
that communicating between two forms in the same executable is dead
easy, but between two different executables is much more involved.

Groetjes,
Maarten Wiltink

.

Quantcast