[Solved!] Weird behaviour in FormCreate

[heebiejeebies]

Hi all,

I recently wrote a routine to load user preferences from an SQL file at load time.  I put the code in the FormCreate procedure of Form1.  Most of it works well, except for the following strange behaviour.  Currently I only have 3 preferences, and after loading the data and placing it into global variables, I then need to update the preferences screen (which is Unit2) to correctly reflect the settings.

Code: Pascal  [Select][+][-]

1. PreferencesForm.DefaultHomeScreen.Text := DefaultHomeScreenPref;
2. If OpenModuleWalkThroughPref = 'True' then PreferencesForm.OpenModuleWalkThrough.Checked := true;
3. PreferencesForm.UserFilesDirectoryField.text := UserFilesDirPref;
4.  

Now the strange thing is, this works perfectly fine if I put the code into a button on Form1.  But if I put it in the FormCreate procedure then, it still compiles, but I get the following error:

"Project raised exception class 'External: SIGSEGV'.

 In file 'unit1.pas' at line 1411:
PreferencesForm.DefaultHomeScreen.Text := DefaultHomeScreenPref;"

 

I even tried calling the button procedure from within the FormCreate procedure, but the same thing happens. If I comment out the first line of the code, then it complains about the second, and so on.  What the...?

[engkin]

I guess the other for is *not* created yet?

[heebiejeebies]

That's probably it - but still a bit confusing because when I call it through the button, the form is not yet visible either.  It only becomes visible when you call it through the Preferences option in the menubar.  So I would have assumed that FormCreate would not be called for Unit2 until that point anyway.

But that gives me a possible solution of just adding the code to the Menuitem procedure.  Let me see how that goes.  Thanks!

[engkin]

We don't need to guess, just check the form variable. If nil or not

Based on your settings your forms will get created one after the other. I believe your code is in the main form. That means when you run your code in OnCreate event, no other form is created yet.

[lucamar]

That's probably it - but still a bit confusing because when I call it through the button, the form is not yet visible either.  It only becomes visible when you call it through the Preferences option in the menubar.  So I would have assumed that FormCreate would not be called for Unit2 until that point anyway.

FormCreate is called when the form is ... well, created. It has nothing to do with whether it's shown (i.e., "visible") or not; it's perfectly "legal" to create a form but don't show it until later (if ever!).

You can test this yourself: create a new application with two forms and make sure both of them are in the "auto-create" list, but set the second form's (the one that is NOT the application's MainForm) "Visible" property to False in the Object Inspector. Then run the application

[heebiejeebies]

Thanks guys!  Well that was a pretty simple answer to a baffling problem.

My solution was just to put the code in the Preferences menuitem, and it works fine. 

[lucamar]

Another solution is to defer those kind of initializations to the OnActivate event handler, though then you'll have to set some kind of flag to avoid doing it every time it's called or, if if it's the only it does, by making sure it gets called only once (by setting OnActivate := nil on entry to the handler).

But yes, if you can in fact wait until some menu item is clicked that's probaby the best solution ... with the same caveats as above re. making sure that (or similar) particular initialization code is called only once.

[dbannon]

I think I would take a slightly different approach.  You initially were reading the preferences in form1's create  and poking some preference into form2. And hitting Form2 before its created.

A better way to do it is to keep those preferences in Form1 and in Form2's create, go and get them from Form1.

All the preferences can sit in Form1, perhaps as vars, maybe properties.  As your app scales up, that approach is essential.

Davo

[wp]

I would not do it this way. When all the settings are in Form1 then Form2 must "use" Form1 in order to get access to the settings. But on the other hand Form1 (which seems to be the main form) must "use" Form2 in order to display Form2: Form2 uses Form1, and Form1 uses Form2. Therefore we have a cyclic dependence. Lazarus can handle this situation when these units are put into the implementation's uses clause. But when a simular situation occurs with other units it could soon happen that the cyclic dependence cannot be handled any more and Lazarus will refuse to compile the project.

It's better to aim for a "star-like" dependence. In the center of the "star" there should be a unit "Globals" with all the project-wide type declarations and variables, among them the settings. Every unit is allowed to "use Globals". This way Form2 finds the settings without having to know Form1, and the cyclic dependence is avoided.

[heebiejeebies]

Thanks for the input guys!  I'm a little bit confused though... The way I was planning to do things is to read the prefs from the SQL file at startup, put them into the preferences screen upon the menu call, then save them back into the SQL file when the prefs box is saved.  It is modal, so it doesn't need to affect any behaviour of the program while it's open anyway.  Then obviously the main unit needs to reload and apply the SQL file once the prefs box is closed.  Is there a disadvantage to doing it this way?  I will probably have fewer than 10 preferences in the finished app so it seems to me that this is the simplest solution, and a workable one.

[jamie]

Use the OnCreate in the last form in the auto create list.

The forms are created in the order they show in the auto created list and if you depend on items being valid before they show and user interacts with them you can use the last auto created form and take advantage of the OnCreate event there.

 That should work for you.