Automatic Form Creation...

[JaedenRuiner]

This is odd, because well it is sort of a hack, so I'll try to explain.

On other posts I mention trying to add settings to the My.Settings object to dynamically at run-time, and still have them saved to the user.config file along with the static settings created in the designer. This can be done, but it takes a little effort.
First, each property that is going to be added to the "user.config" file must be create with the correct SettingsProvider, and flagged with the User Scope Attribute. So when the program is loaded, the Settings property initially begins with the Static settings (from the designer) but when you add the dynamic settings to the Settings Object, it automatically re-examines the provider and loads those values as well.
So, for example there are Static Settings:

• Form.Location
• Form.Size

These are loaded at start up. Then in my form I add Form.SplitContainer1.SplitterDistance as a property (named "Form.SplitterDistance"), and suddenly that value: My.Settings("Form.SplitterDistance") is a valid setting with a value loaded from the user.config file, and when that value is changed it saves them back to the user.config file on application exit. This works great. I've even designed a layout manager, where I can pass a form, and provide Control Types and Property Names, and using reflection the Manager recurses through the Form controls and create's SettingsProperties for each control of the specific types and their subsequent Properties that exist for that control.
Idea: I have 6 basic layouts for my AdminForm, all pertaining to SplitContainer Panels being Collapsed or visible, and Splitter Distances being preset to a user configured layout. There are simply too many to really make it worth my time to waste the hour+ to manually configure all of these settings in the Settings Designer, so using this dynamic method I don't have to ever again worry about the Settings creation for form layouts.

However, the problem is that AdminForm is not my main form, it is secondary to MainForm the application's main form, which loads the AdminForm. So, as the problem of hacking the my.Settings object in such a manner arises, if I do not Load the AdminForm, the Settings Properties are never created for it, and thus when I exit the application the new user.config file overwriting the loaded one does not contain any of the dynamic settings properties. Obviously, I must create the settings properties upon application start up, but that requires the Admin Form to be "Loaded".

That's where i'm running into a glitch. the Load event seems to be called when the Show() method is called for the first time, or each time the ShowDialog() method is called. Since this is not a modal dialog, I use Show() so the user can flip back and forth between the two forms without issue. However, the AdminForm is not always necessary, so I need a way to "create" the layout into the settings property when the mainform is loaded.

private Sub Main_Load(<params>) handles Me.Load
  My.Forms.AdminForm = New AdminForm()
end sub

That didn't work, as the error came back saying I could only set that property to nothing. it appears that the AdminForm property is already set to a "valid" instance of the AdminForm, so I tried to call the Load() event method from MainForm.Load, but when I Show()'ed the AdminForm for the first time, it called the AdminForm.Load() event again.

Additionally, I noticed that many of my forms which are truly only best used on the fly:

public Sub MyDoSomething()
  dim frm as new MyForm1()
  frm.Property = Value
  if frm.ShowDialog() <> DialogResult.Cancel then
  end if
  frm.close()
  frm.dispose()
end sub

The Application still creates an instance of these forms in memory that are never used. So, what I'm looking to find out is:

• Is there an application setting or program option that allows me to determine what forms are created initially on App Startup and Which forms aren't, basically allowing the My.Forms property to contain a bunch of "Nothing"s until I decide a form should be instantiated.
• Upon Startup, are all the Forms listed under the My.Forms.<FormName> properties automatically created via their Default Contructor already, and thus could I put my layout creation and settings manipulation in the constructor after the "InitializeComponents()" line?

Based on the design of the application, I only need two of my 6 forms loaded at start up, since the other 4 I never access via the My.Forms.<FormName> construct, I create/dispose them at run-time. And the Forms that are created at startup need to have certain things done to be assured they are handled correctly, which means I need to make sure that when my first main form is shown, that all the controls private fields for my other secondary forms are fully created for my layout manager to parse.

I think this is clear enough, but i can provide more indepth detail if necessary. Primarily if I can turn off the "form Autocreate" that would be enough.

Thanks

 

[JohnH]

The Application still creates an instance of these forms in memory that are never used.

No, default forms are only instantiated if you access them by setting/getting a property or calling a method, if you just check if it is Nothing it is. If you set a Date stamp in constructor you can see when it was created.

Will the CreateControl method resolve the issue? (Load event is still only raised when and if the form is first Show'ed.)

 

[JaedenRuiner]

No, default forms are only instantiated if you access them by setting/getting a property or calling a method, if you just check if it is Nothing it is. If you set a Date stamp in constructor you can see when it was created.

I found this out, *chuckle* the hard way. doing a If Forms.AdminForm isnot nothing and my code in the if block never executed.

Will the CreateControl method resolve the issue? (Load event is still only raised when and if the form is first Show'ed.)

I'm not sure. I ended up resolving the issue based on the knowledge that the AdminForm would be created the moment I accessed the Property, so I set up a friend method that I call from the MainForm.Load() event handler.

That seemed to resolve the issue. It is good to know that the forms are only loaded once you access the property, at least then I know all that memory hogging is indeed my fault.

I also found some of the issue was with the fact that when you create a new setting with Settings.Properties.Add(), you have to also add a value with Setting.PropertyValues.Add() that points back to that property. The ApplicationSettingsBase Class is not that intuitive. But the system works, so I'm happy.
Thanks