Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Close form or make invisble ?

Status
Not open for further replies.

Guthro

Technical User
Sep 9, 2006
107
GB
I'm attempting to write an invoicing/stock control program for our family business. A never ending task lol.
After a long break I've decided to start with a clean sheet of paper and a blank Form.
So its back to basics of programming.
The first basic question is should I make a form invisible or close it ?
Assume you start with a form with several buttons the take you to other forms. All the form does is help you navigate to another section.
Is it good practice to close the form you're moving from and then open the form you're moving to or make the form visible/invisble ?
Using a BitBtn, it has a Kind property with a value BkClose. This closes the form. Yet, if I want to allow the esc key to also close the form, I have to do an onclick event. Should this be set to Form1.close or can I somehow link the esc keypress directly to the BitBtn Kind property ?


My Feeblegirl.com Forum boards for mmorpgs, sport, fun, politics...
 
I generally Hide (Form1.Close) forms that I will need to reuse often, and Free (Form1.Release) forms that I won't. You'll save memory by freeing the forms and recreating them, but I imagine there may be a time penalty for recreating the forms. Particularly if they contain components that need to retrieve data, access datasources, etc. By Closing/Hiding the form, all of these connections remain open.

A quick peek at the code within TCustomForm.Close shows that this may not apply if you're closing the main form.

As to whether you create a duplicate event method to handle pressing Escape, or try to link Escape to the BitBtn can be debated either way really. On one hand, it adds duplicate code, on the other it may become less clear on how your program works.
 
If the purpose of the form in question is just to enable navigation to other forms where the work is actually done, why not just use a normal menu?


Hope this helps.

[vampire][bat]
 
Thanks for the input guys.

earthandfire I assume by "normal menu" you mean a drop-down menu. I will be adding this to work alongside the on screen buttons. Our current software uses buttons on a screen to navigate to Sales ledger, Purchase Ledger etc and I'm trying to keep some similarity in "feel" between the old and the new for the benefit of non computer literate users.
I also find it a lot quicker to use tab and return to choose an option instead of grabbing the mouse.
Thanks for the response.

My Feeblegirl.com Forum boards for mmorpgs, sport, fun, politics...
 
It sounds as though this may be a good example of when to use MDI forms. You could create an MDI parent form (i.e. set the FormStyle property to fsMDIForm) and on this form use a TMainMenu (as earthandfire suggested) to provide the user with a way of accessing the other forms. These other forms should have FormStyle fsMDIChild so that they may be contained within the parent.

For the Close button, if you set the Cancel property of a TBitBtn to True then it will respond to the ESC key, however Delphi will force the Kind property to bkCustom. If you want to respond the the ESC key then the simplest way would be to set the Cancel property to true and have an OnClick handler that just contains Form1.Close, as you suggested.

HTH

Steve
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top