Control class object for the form itself

Ask questions about creating Graphical User Interfaces (GUI) in PowerShell and using WinForms controls.
Forum rules
Do not post any licensing information in this forum.

Any code longer than three lines should be added as code using the 'Select Code' dropdown menu or attached as a file.
Locked
User avatar
Lembasts
Posts: 301
Joined: Thu Mar 15, 2012 9:47 am

Control class object for the form itself

Post by Lembasts »

Greetings,
I can get a collection of Control class objects for the form's immediate children by accessing the controls property e.g. $formMyform.controls
How do I get the Control class object for the form itself?
Thanks
David

jvierra
Posts: 14476
Joined: Tue May 22, 2007 9:57 am
Contact:

Re: Control class object for the form itself

Post by jvierra »

What do you mean by this. The form is a class. The "Control" property is the container for the forms controls. The form does not exist in a container. It is a top level object. Its only parent is the thread that started it.

User avatar
Lembasts
Posts: 301
Joined: Thu Mar 15, 2012 9:47 am

Re: Control class object for the form itself

Post by Lembasts »

I take it the answer is no then.
That's sorta what I thought.

jvierra
Posts: 14476
Joined: Tue May 22, 2007 9:57 am
Contact:

Re: Control class object for the form itself

Post by jvierra »

I can't say no because I don't understand why you are asking that question. What is it that causes you to ask that?

Note that in science, technology and most of life all questions need a context. Your question has no context for me because I have no clue as to the purpose of the question.

User avatar
Lembasts
Posts: 301
Joined: Thu Mar 15, 2012 9:47 am

Re: Control class object for the form itself

Post by Lembasts »

I was after the control object for the form.
The object that has the properties etc for the control class:
https://docs.microsoft.com/en-us/dotnet ... etcore-3.1
I can get the control objects for every other control on the form but not the form itself.

jvierra
Posts: 14476
Joined: Tue May 22, 2007 9:57 am
Contact:

Re: Control class object for the form itself

Post by jvierra »

The forms properties are the properties of the forms control class. A form is not a simple control. It is inherited from the control and container classes and is a new and independent type.
All controls are inherited from "System.Windows.Forms.Control". This has noting to do with any control being "hosted" by a container class.
Please go back and read the docs on what WinForms are and how they are structured. You may also need to learn what "objects" and object programming is and how it works. Without a clear understanding you will get confused about what can be done and what can't.

To get the class of any object use "GetType()".

$myForm.GetType()

User avatar
Lembasts
Posts: 301
Joined: Thu Mar 15, 2012 9:47 am

Re: Control class object for the form itself

Post by Lembasts »

I know what objects and object programming is. Probably best not to complicate the answer to questions.

jvierra
Posts: 14476
Joined: Tue May 22, 2007 9:57 am
Contact:

Re: Control class object for the form itself

Post by jvierra »

From your questions it is clear that you don't know the details. Like many you likely know about it but not to any deep technical level. I say that becasue so many of your questions show either a lck of understanding or incorer4ct understanding. This is no unusual. I have worked with programmers who felt they understood but it turned out that they didn't. So9me I was able to redirect and others refused to erview what they thought they knew.
It is almost impossible for anyone with no formal programming training to understand object systems. Understanding event driven object systems designed to allow us to create "state machines" in code with objects is difficult because the training needed requires some sense of what a state machine is and how it works.
Yes - PowerShell and Sapien give us an entry-level shot into this world but, without some formalism around this system, it is a challenge. It nearly always requires that someone new to it review the structure and implementation of the system repeatedly until a clear understanding is obtained.

You are doing well but you keep getting stuck where you would not be stuck if you had the understanding of how the system works.
Just consider this - Windows Forms is a "system". It is designed to be used in a specific set of ways. Deviating will create conflicts. Incorrect design approach will create conflicts.

I had a good friend and co=worker who was an excellent programmer outside of Windows. He had years of experience. He died on Windows. Later he went to a school to learn Windows Programming and design of Windows based systems and finally learned what he couldn't figure out. He became adept at Windows forms programming. The school was full time for six months.

Using Forms with PowerShell does not take that much if the formalities are learned first. I just want to point out that it is a challenge that needs to be addressed. You have a good start. Go back again f4om the beginning and many new things should become clear.

Remember that we have to think in events and know the order of events as well as know which controls are designed to allow us to build manageable forms. Forms are not just a bunch of things that can be stuck together in any way you like. There is a method to how this is intended to work. It is flexible but some choices will get a forms builder into trouble and make the project difficult and fragile.

One huge deficiency in WinForms is that it cannot do many of the things you see in modern Windows. It is an older development of the forms concept. Newer tools like WPF/XAML can do more and allow us to develop even better and more flexible forms easily but the technology is very challenging to learn. Many PowerShell users assume that what they see in modern Windows can be done with WinForms. Many things cannot be done except by adding third party controls. Some things cannot be done at all using PowerShell. Understanding the intent and limits of WinForms is critical to understanding how to design forms.

There are many books covering all of this. All are written for compiled languages and not for PowerShell. Converting from any compiled language to PowerShell with forms is not a good method due to how PowerShell accesses the forms objects which is much different from how we do it in a compiled language.

Good luck but keep trying to gain that deeper understanding of how forms work. Over time many issues will become clearer and you will reduce the code you write (the original purpose for MS creating WinForms) and you will see more quickly how to design a set of forms.

[a little aside from history]
In the beginning we built Windows from scratch. We had to define the frame and each element in code. This was tedious. Later we got MFC which gave us class templates to build code from and better tools to do layouts. Better but still tedious. When Net wa developed MS seminars showed us how Forms would be easier and code would be simpler. MS tests had shown that using Net reduced code time and complexity by something like a factor of 200 against all other products,

Locked