killer5
asked on
Instantiate a form by name
How can I instantiate a form by its name?
somewhat like this....
Dim myForm as New ("frmMainMenu")
somewhat like this....
Dim myForm as New ("frmMainMenu")
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Dim sForm As String = "WindowsApplication1.Form2
Dim frm As Form = _
DirectCast(Activator.Creat
frm.Show()
iboutchkine, what's the difference between your code and mine?
[NOT AN ANSWER TO THE QUESTION]
wguerram: Let me jump in here and take a shot at that.
[ I hope this serves as a good illustration of good coding practices, and how to write for the reader. (No offense intended. I'm not implying you don't do that.) This is such a tiny piece of code, yet offers many possibilities of variation. I'm just trying to "plus" this discussion. ]
(1) sForm is broken out separately, which allows the rest of the code to be easily parameterized. It better illustrates that the code can be used for any particular form name.
(2) It creates frm, a Form object, which can be used in later code to manipulate the form that's been created.
(3) It uses DirectCast. This is better than CType in this case, because the programmer already knows that the thing that's being cast is a kind of Form (i.e. derived from the Form class). Therefore DirectCast will always work, and it will be faster than CType.
(4) The code is broken up into 4 lines (3 statements), which makes the intent of each line clearer, and is easier to read. It can also be easier to debug, because the exception/debugger will identify the line where the exception occurs, and this separates out the two critical parts of the function (creating the form, and showing the form).
(5) It answers the original question better. It clearly breaks out the actual answer from the supporting code. The actual answer is just the middle statement, without referring to a specific form name and without showing the form.
(6) It takes into account that the primary reader of the code is another programmer, not just the computer/compiler.
(7) It's readable even for beginning programmers, though the middle statement is still pretty difficult. There's not too much happening all in the same line.
(8) Because it's well broken out, the second and third statements are copy-and-pastable. It doesn't have that nasty string literal in the middle of it.
iboutchkine: Anything to add?
wguerram: Let me jump in here and take a shot at that.
[ I hope this serves as a good illustration of good coding practices, and how to write for the reader. (No offense intended. I'm not implying you don't do that.) This is such a tiny piece of code, yet offers many possibilities of variation. I'm just trying to "plus" this discussion. ]
(1) sForm is broken out separately, which allows the rest of the code to be easily parameterized. It better illustrates that the code can be used for any particular form name.
(2) It creates frm, a Form object, which can be used in later code to manipulate the form that's been created.
(3) It uses DirectCast. This is better than CType in this case, because the programmer already knows that the thing that's being cast is a kind of Form (i.e. derived from the Form class). Therefore DirectCast will always work, and it will be faster than CType.
(4) The code is broken up into 4 lines (3 statements), which makes the intent of each line clearer, and is easier to read. It can also be easier to debug, because the exception/debugger will identify the line where the exception occurs, and this separates out the two critical parts of the function (creating the form, and showing the form).
(5) It answers the original question better. It clearly breaks out the actual answer from the supporting code. The actual answer is just the middle statement, without referring to a specific form name and without showing the form.
(6) It takes into account that the primary reader of the code is another programmer, not just the computer/compiler.
(7) It's readable even for beginning programmers, though the middle statement is still pretty difficult. There's not too much happening all in the same line.
(8) Because it's well broken out, the second and third statements are copy-and-pastable. It doesn't have that nasty string literal in the middle of it.
iboutchkine: Anything to add?
Well farsight, what can i say.
I am totally agree with you. it's just that at least iboutchkine would have mention that the code is kind of a derivation of mine, and explaining the reason why shouldn't use mine, as you did.
I was just thinking on making the code smaller.
:-)
I am totally agree with you. it's just that at least iboutchkine would have mention that the code is kind of a derivation of mine, and explaining the reason why shouldn't use mine, as you did.
I was just thinking on making the code smaller.
:-)
ASKER
I really appreciate your comments guys!
thanks a lot!
thanks a lot!
CType(Activator.CreateInst