Items in Containers not being seen elsewhere?

Getting Started
1

I have placed text fields in containers on their own window and now would like to collect the .txt values from those text fields in a single variable which I then can use to create the PDF output. However, I notice that the text fields are not being seen anywhere else, is this because they are placed in a container?

2

Yes. They are encapsulated in the container. It’s not best OOP practice, but you can access them by referring to the container, eg., Container1.Textfield1.Text.

3

Ah, I see, so I need to set the path to the text field to get the values? Thanks.

4

The item cannot be found still, even though I set the complete path:
WinHeroActionHeroQuestions.CCHeroQuestionList1Applied.Text_Heroabilities.text

The text field is placed on a separate Window, then inside a Container. I am trying to get the text value from this field.

5

Ah, it seems it also matter from where I call it. The button that runs this code was placed on another Window.

6

If you are trying to access the text field from a different Window you have to also specify the window :
WindowName.WinHeroActionHeroQuestions.CCHeroQuestionList1Applied.Text_Heroabilities.text

1 Like
7

Let me propose an alternate technique. To help keep your code more adaptable in the future, set all your controls in all your views (windows and containers) to private. This means Window1 cannot access the controls on Window2, nor could it access the controls inside a container placed on it. This allows you to essentially write rules for how these pieces work together. If you wanted the text property of text field on Window2 to be accessible to Window1, you’d add a method to Window2. So instead of Var UserEntry As String = Window2.TextField1.Text you would write Var UserEntry As String = Window2.TheMethodName. This sounds like splitting hairs, but it gives you a lot of power. First, Window1 cannot change a single thing about the text field. It can’t be moved, or contents changed, or anything at all. Window2 remains in control. On top of that, Window2 isn’t even exposing that the value is coming from a text field, which is where the real power comes from. You could add logic to the TheMethodName accessor method that uppercases the result, for example. You could even change the text field to a combobox, and Window1 would be none the wiser. If you needed to be able to set the value from Window1, you could add an assignment method (TheMethodName(Assigns NewValue As String)) or switch to a computed property.

This technique essentially turns each of your views into mini programs, each with their own inputs and outputs, who are responsible only for themselves. By reducing what each view knows about another, you give your code room to grow with greatly reduced risk of becoming a spaghetti nightmare.

5 Likes
8

Thanks, this feels like a very good idea. I will use this approach when starting to make reports.