How to manipulate controls of a newly created instance of a form?

Question

1.00/5 (1 vote)

See more:

The following is supposed to run after

VB.NET

TwoSecondTimer.Enabled = True

is executed in my Public Class Root right?

VB.NET

Public Module Timers
    Public WithEvents TwoSecondTimer As New Timer With {.Interval = 2000}
    Sub TwoSecondTick() Handles TwoSecondTimer.Tick
        Root.AddToMessages("tick")
        Root.AddToMessages(Main_Window.Cash)
        Main_Window.Cash += Main_Window.Income
        Main_Window.CashLbl.Text = "¤ " & FormatNumber(Main_Window.Cash)
    End Sub
End Module

Thing is the timer is not enabling when told to. Even if enabled by default, the timer code still doesn't work anyway...

...Root.AddToMessages works, but the two lines involving Main_Window don't. Root is my first form, Main_Window is one of the forms being instantiated through reflection. There are no errors during runtime, the Cash variable just doesn't change from it's default value and CashLbl.Text never changes.

Edit:
So the timer can't be enabled from my Root class and Main_Window controls/variables can't be modified from my Timers Module. What am I forgetting?

If I modify my code in ways necessary to change TwoSecondTimer and TwoSecondTick to be Shared, then I get the error NullReferenceException.
The previous was solved by changing Forms.Timer to Timers.Timer, since the timers were created in a module instead of on a form.

Note, the forms are created as such:

C#

Dim NewWindow As Form = CType(Activator.CreateInstance(Type.GetType(AssemblyData.GetName & "." & sender.text.replace(" ", "_"), True, True)), Form)

So if a reference to the newly created instances of Main_Window is needed, how could I create one and link it with a form in order to manipulate the form?

Posted 24-Jan-16 11:13am

ChaosOverlord_

Updated 26-Jan-16 13:21pm

v6

Add a Solution

Comments

Sergey Alexandrovich Kryukov 24-Jan-16 19:39pm

Is it System.Timers.Timer? Did you call Timer.Start? Why using a timer at all? Did you consider using a separate thread instead, which is less dangerous? Do you use any UI in a timer tick handler? If you do, you need to use Invoke or BeginInvoke, methods of System.Windows.Forms.Control (for Form applications only) or Dispatcher's methods.
—SA

ChaosOverlord_ 25-Jan-16 2:23am

It's not, turns out changing to a system.timers.timer was indeed a solution to one of my problems, thanks!

Invoking has no effect (even after testing it anyway, invoking just isn't required)

Since Main_Window has a new instance of itself being created during runtime, could it be that modifying a variable or control within Main_Window (ex. Main_Window.CashLvl.Text = "xxx") is actually trying to reference a previous instance instead of the newly created one?

If so, would adding NewWindow into a global public collection (ex. Public CreatedForms as FormCollection) allow me to reference this new instance, or would it be better to attempt to reference the form through Application.OpenForms?

Sergey Alexandrovich Kryukov 25-Jan-16 9:33am

Do you mean that InvokeRequired returns false?
Messed up references could only be possible if you mess them up yourself... :-)
—SA

ChaosOverlord_ 25-Jan-16 18:00pm

Yes InvokeRequired is false.

I'm not sure how I could have messed up though. In my code I'm directly calling Main_Window. Since multiple instances of Main_Window can exist at once, I suppose I need to reference an instance in particular but I don't know how to do that.

Sergey Alexandrovich Kryukov 25-Jan-16 18:31pm

I don't understand the problem with reference. It's up to you to provide a reference. Is it a problem of collaboration between different form/window instances? It's a pretty simple stuff. And again, what's the goal of bi-second events?
—SA

ChaosOverlord_ 25-Jan-16 20:21pm

Dim NewWindow As Form = CType(Activator.CreateInstance(Type.GetType(AssemblyData.GetName & "." & sender.text.replace(" ", "_"), True, True)), Form)

The previous code is creating new instances of a form. Calling a class name is not correctly referencing the newly created instance.

Sergey Alexandrovich Kryukov 25-Jan-16 21:59pm

Why? This is the reflection technique.
—SA

ChaosOverlord_ 26-Jan-16 4:38am

It is because I wanted to be able to add new forms to my project without having to also manually instantiate each form by name. The user clicks a button on the Root form and it instantiates a form that matches with the button the user clicks. My goal is to be able to rename/add new forms seamlessly.

I believe I have worked out a solution to my particular problem, will be describing it as a solution to this question when I have time to sort out all the specifics, in case you're interested.

Sergey Alexandrovich Kryukov 26-Jan-16 10:28am

It does not makes any sense. You should create forms using a constructor, but you are using a reflection technique and not even trying to explain this weird decision.
—SA

ChaosOverlord_ 26-Jan-16 17:03pm

Unless I'm missing something, I've already explained this.
"It is because I wanted to be able to add new forms to my project without having to also manually instantiate each form by name."

Project->Add Windows Form

That is all I have to click to add a new form. My program creates a new button assigned to that newly added form and my program can already instantiate it through that button. A 2 click process in all.

I'm in a learning process here as well. Not any kind of professional. Trying to find the fastest ways to create large projects, not necessarily the easiest.

Sergey Alexandrovich Kryukov 26-Jan-16 18:17pm

Probably you are missing something. There is no such thing as "project" during runtime. "Instantiate form by name" is absurd (however possible) even when you need reflection. You only know reflection if you want to load an assembly not known during build, which is dynamically supplied from some source, without a need to stop the process. When you say "add a form", it means adding a type or adding an instance. You can add a new type dynamically during runtime: System.Reflection (with a new assembly developed separately), System.Reflection.Emit or CodeDOM. But this is only needed if you want to work with some type totally unknown during build. To create an instance of a known type, you simply use the constructor. (With Reflection, you first obtain the constructor from an instance of System.Type.)

"From name" is bad (practically, unacceptable for most applications), just because it is poorly maintainable. The civilized way is to have an interface known to both host application and "plug-in" assembly, which should be implemented in a plug-in. This way, you find a type by this criterion "implementing the interface", which eliminates "magic string" anti-pattern. This is fairly simple, unless you also need to unload some assembly, to load a different one. The only problem is that there is no a way to unload an assembly, so you have to load it in a separate application domain; and working through the boundary between application domains is another complication. So far, you gave no justification for using anything like this at all, unless you have something else to do, which you did not explain.

—SA

ChaosOverlord_ 26-Jan-16 19:12pm

"There is no such thing as "project" during runtime."
I am referring to making the actual programming of the project easier. By adding forms to my project I was referring to adding forms during development of the project.

I suppose I still don't understand the full scope of reflection, just as I don't fully understand some of what you said in your comment, so I will have to spend time researching and learning about everything you spoke of.

"So far, you gave no justification..."
Basically, the way I am pursuing is the only way I can figure out how to make this work at all in the exact way I am aiming for.

I want a single subroutine to handle events from multiple buttons.
Buttons are created at runtime after looping through all existing forms of a particular nature and creating a matching button for them.

The subroutine knows which button was clicked through the sender parameter. As a result, Sender.Text is what my code uses to determine which form needs to have an instance of itself created. To avoid a Select...Case statement necessary to execute a constructor, I take advantage of the dynamics of reflection; hence my all-in-one 1 line instantiation that will never require further editing no matter how many new forms I add to my project during development.

Sergey Alexandrovich Kryukov 26-Jan-16 19:48pm

Okay, "the only way I can figure out" tells nothing. It becomes apparent that you have no idea what you are doing. It simply means that you won't be able to continue how things work. Amazingly, it's much simpler that you imagine. You did not give me any confirmation that you are adding any types dynamically during run time. If this is still true, you should not do what you are doing.

To start with, here is what happens with forms. You define one or more form classes:

class MyForm : System.Windows.Forms.Form { /* members specific to your form type... */ }
..///

myForm = new MyForm();
// that's all!

"Single subroutine is to handle events" is totally trivial. You just use += operator on different event instances, on left of it, but the delegate or right is the same. How could it be a problem?

All right, from this point, you can develop anything reasonable only you forget about Activator. And keep it forgotten until you understand what is reflection and until you really need it.

—SA

ChaosOverlord_ 27-Jan-16 21:05pm

Activator is completely out of my head now.

Ok this is the clearest comment of all in regard to forms and events. C# syntax is still strange though. (I'm purely VB.Net)

So if I have a class named 'Root' containing a form, to create a non-default instance I can use:
"Public NewRoot As New Root" in order to create a new instance of the class/form?

And this new instance can be referenced from other classes by:
Root.NewRoot ?

Sergey Alexandrovich Kryukov 27-Jan-16 21:38pm

You have to come from first principles. A member of a form type is no different from any other member. It's all about this: instance members vs static members...
If your NewRoot is an instance member, you can only access it as
someRootInstance.NewRoot, where someRootInstance has the type Root. If this is a static member, you use Root.NewRoot. Isn't that obvious?

I'm starting to have bad feeling now. Do you know OOP? Do you know how to override virtual methods, not formally but to achieve late binding. How dynamic dispatch works? And why dynamic dispatch allows to implement polymorphism? Do you understand where VB.NET Self comes from at the call? Your question above makes me doubt. And here is what I think: if you are not comfortable with all this fundamental stuff, you should better stop development of any UI until you are ready for it. Otherwise only frustration and a lot of time waste lie ahead of you...

—SA

ChaosOverlord_ 27-Jan-16 22:28pm

I am familiar enough with OOP on any good day, but I learned almost entirely by myself in an informal way so the how's and why's don't always come very quickly. After looking up all your terminology I can confirm I understand each of what you mentioned, just much slower of course.

"It's all about this: instance members vs static members..."
Now that you mention this it does seem quite obvious. Your explanations are quite a bit clearer than what's in my head, like I said it's just the terminology making me slow.

Sergey Alexandrovich Kryukov 27-Jan-16 22:37pm

Good... But, well, anyway, if you say "...quite a bit clearer than what's in my head", it's still a sign that you still have to gain enough confidence in the fundamentals. So, my advice remain valid... :-)
—SA

ChaosOverlord_ 28-Jan-16 2:42am

Yes lol you are right in the end I still have loads to practice.

I've scrapped my old project entirely and started anew, only copying over what's necessary. My new iteration puts into practice all of your advice to the best of my ability and turned out to be much more efficient.

I thank you graciously for your mass of help, and have selected your Solution #4 as the solution since it was a huge factor in my improvement.

Sergey Alexandrovich Kryukov 28-Jan-16 9:06am

You are welcome.
—SA

4 solutions

Solution 3

ChaosOverlord wrote:

Ah, so if I am to create a lot of different controls, then there is no way of avoiding a large amount of code to create all of the controls?
Also, if these controls are better to be created locally, then what is the best way to call these controls from other subroutines or classes?

Wrong. The number of controls is not translated into amount of code. You avoid large amount of code by abstracting out common functionality of different controls and other elements. Your code is only as complicated as different algorithms are. If you use the same algorithm for many controls, the number of them is majorly absorbed. You have to spot common elements of behavior and never ever repeat yourself. Please see: Don't repeat yourself - Wikipedia, the free encyclopedia[^].

—SA

Posted 26-Jan-16 21:40pm

Sergey Alexandrovich Kryukov

Solution 2

By containing the form reference in a global collection such as this;

VB.NET

Public OpenedWindows As New List(Of Form)

The instance can be referenced from anywhere else in the project by searching through the collection and matching the Form.Name with the form you are trying to modify.

A better way of doing this is by using a Dictionary, since you don't have to loop through a collection. Instead, dictionaries allow the use of a key.

VB.NET

Public OpenedWindows As New Dictionary(Of String, Form)

In the dictionary, the form name (or any chosen unique identifier for that matter) is used as a key. Calling the reference and changing a property of the form is then as easy as;

VB.NET

OpenedWindows("Unique Indentifier").Text = "New Title"

If you want to modify a control of the form, the best method is to reference them through the constructor, however if instances are created using other means, then that solution does not apply. If that is the case, either use a similar method of keeping the form's controls in a collection or search through the forms controls until you find what you are looking for.

For Each _Label As Label In OpenedWindows("Unique Indentifier").Controls.OfType(Of Label)
                    If _Label.Name = "TestLabel" Then
                        _Label.Text = "It works!"
                    End If
                Next

Posted 26-Jan-16 12:49pm

ChaosOverlord_

Updated 26-Jan-16 13:33pm

v2

Comments

Sergey Alexandrovich Kryukov 26-Jan-16 19:49pm

All wrong. You should never use form Name. Why? It makes no sense at all.
Do you really think this is the "solution"? You self-accepted it as solution. Why?
All this "search" will work, of course, only it makes no sense at all.
I would ask you what you ultimately want to achieve (ultimately, that's it; "manipulate controls of a newly created instance of a form" cannot be a goal, it may have some purpose), but I'm not sure you can answer... Will you?
—SA

ChaosOverlord_ 27-Jan-16 0:58am

I posted as the solution because I tried it and it works. Everything I have been attempting to do is executing as I had hoped. Forms are being created at the click of a button and controls in those forms are being modified.

It isn't the best way of doing it by far I know, but my solution pertains to my particular problem referencing forms created in my particular way.

Ultimately I want to have buttons creating forms and be able to alter those forms from any class, as part of a multi-form UI. I tried to avoid using something as static as a constructor for each form.

Dave Kreskowiak 26-Jan-16 20:02pm

Uhhh...wow. This is NOT the best way at all. You're making it extremely convoluted (not to mention very slow) to change the Text of a Label control.

Your code is not testable, you've completely destroyed any chance of using interfaces, and you've blown separation of concerns clear out of the water.

You're actually making it harder on yourself, not easier. It may be organized to you, but it's a nightmare for the person coming in behind you to support and modify the code.

ChaosOverlord_ 27-Jan-16 1:09am

It's not in general no, but it's a solution pertaining to my particular method of instantiating forms. After implementing the solution above, my program was all working as planned.

I actually don't even know what an interface is, which gives you a better idea of where I am in regard to knowledge of the field. I'm no professional by far.

I already know my method is much harder, it's all trying to find a way to make my code as dynamic as possible. Learning through innovation. Purposely avoiding the use of a simple constructor.

Sergey Alexandrovich Kryukov 27-Jan-16 1:12am

Again, it's all about one thing: you need to explain the ultimate purpose of all this activity. So far, nothing seems to make sense.
—SA

ChaosOverlord_ 27-Jan-16 1:15am

Ultimately I want to have buttons creating forms and be able to alter those forms from any class, as part of a multi-form UI.

Sergey Alexandrovich Kryukov 27-Jan-16 1:20am

What you say has no relationship with your code. "As static as a constructor" is a pure gibberish. What do you mean by that? As you have no clue on that matter, let's go back to your ultimate goal. You have number of forms, with buttons. Some button click create and show other forms. Is that right?

First of all, forget about form names. Forget about Activator, in the sense I explained before.

Add some delegates to the button click events, in that delegate, use form constructors. If it's not statically known what Form type you need, explain the rule for this choice.

But, overall, it's a bad idea to use multi-form UI. Single form (dynamically showing some parts and hiding others) is much better. Look at Visual Studio, for example — only one form/window.

—SA

ChaosOverlord_ 27-Jan-16 1:33am

If I want to create and open 3 forms, I'd have to write:
Dim Form1 as FirstForm
Dim Form2 as SecondForm
Dim Form3 as ThirdForm
Form1.Show
Form2.Show
Form3.Show
I would have a large number of separate forms on my project, each having a different layout of controls. I was hoping to find a more compact way to manage such a list.

Each form has a button dedicated to opening/closing that form. The buttons are created dynamically.

I see your point about Visual Studio. My forms don't have borders, it's actually something like switching tabs in your web browser, with the tab bar being one form and the web pages being other forms, closing and opening as you switch tabs. As a result only 2 forms are visible at any one time.

I'm aiming for a very numerous amount of controls on each form so using the designer window is out of the question if I want everything on one form. I suppose creating user controls designed to contain many controls within them is a good way to manage large numbers of controls? Essentially acting as a GroupBox control, only I'm trying hard to avoid my program looking like a generic windows program.

Sergey Alexandrovich Kryukov 27-Jan-16 2:07am

So what? Create them dynamically. Dynamically add handlers showing a form of one or another type. By the way, didn't you think that the context of each form, even of the same type, could be created dynamically and conditionally? "Managed such a list"? It depends on what should be your managing actions. I see not a single problem. But first thing to conclude is: you never need reflection here. Are you clear about it? If not, I'll explain more.

Many thing you are talking look suspicious. "Numerous amount of controls" is a good sign of poor code and UI design. I can be wrong here, of course. It's just suspicious. And think about a single form.

It's not clear what do you mean by "a generic windows program". I don't know such thing. :-)
But yes, there are very common patterns of UI look and feel typical for very poor developers. As it's well-known, bad thing cluster together tightly.

—SA

ChaosOverlord_ 27-Jan-16 2:53am

"I see not a single problem." That would be because you are far more versed than I :P Don't need reflection, got it.

"Dynamically add handlers showing a form of one or another type. By the way, didn't you think that the context of each form, even of the same type, could be created dynamically and conditionally? "
Could you explain that bit further?

By types of forms, you mean forms that have different properties/controls from one another right?

How does one create contents of a form dynamically? By creating controls and adding them to a global collection, and writing a constructor for them wherever necessary?

In regard to the numerous amount of controls, I am designing a very complicated game with a great deal going on. I haven't gotten far enough to design it yet but you may be right it may be solved through smarter design.

Sergey Alexandrovich Kryukov 27-Jan-16 3:02am

I would explain, but first please tell by what's unclear. You don't know how to add a handler to an event instance? I'll tell you. Using the operator += on the event instance. How to make different form content dynamically? This is how:

Control myControl = ...
// set up properties...
myControl.Parent = myParentControl;

This is totally unrelated to "global collection". It's the best to avoid anything global. You can abstract forms from each other by implementing some interfaces by form classes.

By types of forms, I simply mean .NET type.

—SA

ChaosOverlord_ 27-Jan-16 3:18am

Ah, so if I am to create a lot of different controls, then there is no way of avoiding a large amount of code to create all of the controls?

Also, if these controls are better to be created locally, then what is the best way to call these controls from other subroutines or classes?

Sergey Alexandrovich Kryukov 27-Jan-16 3:36am

Wrong. The number of controls is not translated into amount of code. You avoid large amount of code by abstracting out common functionality of different controls and other elements. Your code is only as complicated as different algorithms are. If you use the same algorithm for many controls, the number of them is majorly absorbed. You have to spot common elements of behavior and never ever repeat yourself.
—SA

ChaosOverlord_ 27-Jan-16 3:51am

So for example, something like this?

Sub ConfigureTextbox(ByRef TxtBx as Textbox, Configuration as Integer)
Select Case Configuration
Case 1
TxtBx.Location = New Point(0, 0)
TxtBx.Backcolor = Color.Green
TxtBx.Forecolor = Color.red
Case 2
TxtBx.Location = New Point(50, 0)
TxtBx.Backcolor = Color.Lime
TxtBx.Forecolor = Color.Black
Case 3
TxtBx.Location = New Point(0, 0)
TxtBx.Backcolor = Color.Yellow
TxtBx.Forecolor = Color.Black
.......

And is it acceptable to create many controls in a loop and store references to those controls in collections?

Sergey Alexandrovich Kryukov 27-Jan-16 3:54am

Why not? It depends on the use of it.
Only it's important to avoid immediate constants, such as 50. It makes code not maintainable.
—SA

ChaosOverlord_ 27-Jan-16 4:25am

So I should always declare such values as constants with a descriptive name?

Sergey Alexandrovich Kryukov 27-Jan-16 10:34am

Something like that. Or calculate using some algorithm. Or take from some data...
—SA

ChaosOverlord_ 27-Jan-16 19:35pm

In my case finding locations will be based on the users screen resolution. I think that makes the most sense.

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Dave Kreskowiak · Accepted Answer · 2016-01-24T13:31:00

Solution 1

Which Timer are you using? If it's the System.Windows.Forms.Timer it has to be placed on a Form in order to work.

Posted 24-Jan-16 13:31pm

Dave Kreskowiak

Comments

ChaosOverlord_ 25-Jan-16 2:25am

Good solution, this fixed my timer problem so thanks, unfortunately this was only a secondary issue.

My main problem remains I am unable to manipulate newly created instances of forms during runtime.

Dave Kreskowiak 25-Jan-16 7:58am

Your code seems to assume that Root and Main_Window are "global" variables defined elsewhere.

Code like this usually sits on the form that has these forms or controls defined in it, not in a separate module.

ChaosOverlord_ 25-Jan-16 18:15pm

Root and Main_Window are both classes (which both do have their own forms if that isn't obvious already)

Tried to move them into a module to make my program more organized since it will become quite large. I had already tried moving the relative pieces of code from the module into the respective form to no avail.

Basically what is revealed by this is that there are indeed new instances of Main_Window being created any time it's opened, so basically I am wondering how to reference those newly created instances. Adding some temporary diagnostic code shows that there are multiple 'Main_Window's active if I open more at runtime, so calling for a variable from outside of Main_Window (by using Main_Window.Cash in my Root class) will only return the *first* instance's Cash variable.

Dave Kreskowiak 25-Jan-16 18:59pm

This is why any code that interacts with a form belong in the forms code, not in a module.

I don't have enough information to tell you what's going on and how to do something. All I can see is the tiny code snippet in your original post.

ChaosOverlord_ 25-Jan-16 20:26pm

"I had already tried moving the relative pieces of code from the module into the respective form to no avail."
---------------
"Dim NewWindow As Form = CType(Activator.CreateInstance(Type.GetType(AssemblyData.GetName & "." & sender.text.replace(" ", "_"), True, True)), Form)"

As in shown my question, this is the code creating new instances of the Main_Window form.

Attempting to call/manipulate controls and variables belonging to Main_Window from my Root class is not referencing the instance of Main_Window that I am attempting to manipulate.

Dave Kreskowiak 25-Jan-16 21:40pm

OK. You've got the reference to the created form in NewWindow. You call the methods and set properties using that reference. That's it.

ChaosOverlord_ 26-Jan-16 4:44am

True, but that is a local variable. I need to be able to reference it from anywhere, not just from the same subroutine.

Furthermore, I don't want to create a dedicated variable manually for each form reference, I want to have it managed through a collection. Advantage being I don't have to manually add a new variable every time I add a new form to the project, and of course I get to learn how it's done.

Partially thanks to you pointing out what you just said, I realize I need to add NewWindow to a global collection. It's a wonder I didn't realize that earlier. Anyway it's finding a specific form reference from within the collection that I am wondering about now. The best way to do it that is.

Not only that, but each form will have entirely different controls within, so I also need to be able to access these controls by referencing through the collection, meaning I'll have to run through all the controls in the form and match the desired control by name, right?

Dave Kreskowiak 26-Jan-16 8:33am

OK, you have to keep that reference in a collection. You don't create another variable.

The problem is how are you going to differentiate between forms in that collection? What is unique about each form that you can use to identify it?

This sounds like you're trying to build overly generic methods to do everything for every form. That's a bad idea if you are.

ChaosOverlord_ 26-Jan-16 17:05pm

Form names are unique.

"This sounds like you're trying to build overly generic methods to do everything for every form. That's a bad idea if you are."
Pretty close actually, for the purpose of accelerating the process of developing large projects. Overall my goal is to learn all the most efficient ways of doing absolutely anything at all, then try to minimize the amount of code I have to write by integrating as much as possible into a universal framework I am building.

How is it a bad idea?

Dave Kreskowiak 26-Jan-16 17:56pm

It's a bad idea because your generic library to manage every form becomes larger and larger with more and more methods supplying functionality to a smaller and smaller numbers of forms.

This also smacks "separation of concerns" in the face. That's not how SoC is done.

ChaosOverlord_ 26-Jan-16 18:11pm

Somewhat true, but I think that depends on organization. I can easily separate into relevant classes or even into different libraries and reference only what is used, and make sure to minimize the number of subroutines and functions by carefully using overloads and extra (+ optional) parameters to give more versatility to the same methods.

I am thinking of the .NET Framework overall. A massive framework but it's organized efficiently.

And btw if I haven't said it already thanks for all the help/advice.

Sergey Alexandrovich Kryukov · Accepted Answer · 2016-01-26T21:50:00

ChaosOverlord_ wrote:

VB

Dim NewWindow As Form = CType(Activator.CreateInstance(Type.GetType(AssemblyData.GetName & "." & sender.text.replace(" ", "_"), True, True)), Form)

I need to summarize the reflection issue and the misconception you have here.

Let's say, by the moment your execution enters the entry point (Main) method during runtime, your whole process have N .NET types loaded. You only need reflection only at the moment you need to introduce the type number N+1 during (the same) runtime. Then you have the such options as 1) load another assembly developed separately, 2) create an assembly by compiling it in the same process using CodeDOM, 3) dynamically create a new assembly using System.Reflection.Emit.

Despite my all my effort, you never mentioned such need. All your considerations were about using the same N types. You cannot use them more "dynamically", because, with fixed set of type, instantiating them with constructors is already as dynamic as it can be. So, from this moment, forget Activator, until you really need reflection or System.Reflection.Emit.

—SA

How to manipulate controls of a newly created instance of a form?

4 solutions

Solution 1

Solution 3

Solution 4

Solution 2

Add your solution here

Preview 0

Existing Members

...or Join us