WebContainer problem

Hi,
I have two questions:

  1. I have a WebContainer Control with some field. I put this WebContainer in a WebPage. How can I refer to this Field? For Example, I have a search bar in Toolbar and i want to filter data into WebContainer Field. How Can i do this? I receive error from the code. The error is “This Item does not exist”.
  2. How can i create the image button?

Thank you,
Andrea.

You need to reference the WebContainer with its name.
For example:

MyContainer.MyField.text = "something"

Thank you Albin,
but i still receive this error in my xojo project:

MyContainer.MyField.text = “something” this item does not exist.
How can I do to resolve this problem?
Thank You.
Andrea

Don’t reach inside a container and set properties, that’ll only get you into trouble.

Instead, create a method on the container such as “SetValue” that takes the value as a parameter, and then uses that value to set the property on the field it owns.

[quote=296495:@Andrea Mario Labate]Thank you Albin,
but i still receive this error in my xojo project:

MyContainer.MyField.text = “something” this item does not exist.
How can I do to resolve this problem?
Thank You.
Andrea[/quote]
You need to use the names of your controls instead. “MyContainer” and “MyField” was just made up :wink:

What kind of trouble?

Access to control’s properties in a container from outside the container itself is very “spaghetti” code.

Big troubles arise when the container is created dynamically: in this case you don’t know when the container and all of its contents is ready (i.e. shown) so you can change visual properties in a safe way.

@Maurizio Rossi sums it up well.

Also, if you want to change the way your Container shows that data, or renamed its controls, moved the field inside an embedded container, or basically did any kind of internal refactoring of the “component”, you’ll have to then update all your non component code that reaches inside.

[quote=296557:@Ian Jones]@Maurizio Rossi sums it up well.

Also, if you want to change the way your Container shows that data, or renamed its controls, moved the field inside an embedded container, or basically did any kind of internal refactoring of the “component”, you’ll have to then update all your non component code that reaches inside.[/quote]
Good reasons :slight_smile:

Thank you so much at all.
Now it is work.
When I use the search bar to find a record on 164.000 Rows in local Local sql Database it takes a long long time. It is a normal behavior? I need to use my application on web server.
Thank you again.
Andrea.

Andrea, how do you implement the search?
Are you sure that is the query so slow? Maybe is the show result phase. How many result do you show?

[quote=296505:@Ian Jones]Don’t reach inside a container and set properties, that’ll only get you into trouble.

Instead, create a method on the container such as “SetValue” that takes the value as a parameter, and then uses that value to set the property on the field it owns.[/quote]

This is very interesting. Is there a “container best practices” guide out there that we can reference? I’ve always reached into the container to change values without issues, so far. The key is the last two words, and I would prefer not to get into future trouble and not understand why.

All this resorts to OOP good habits. As a matter of principle, one is not supposed to reach inside a class to change values, but to use class methods, interfaces or computed properties do do so.

For instance, if you have a TextField inside a ContainerControl, you can do

ContainerControl1.TextField1.Text = "hello world"

But that could be broken if you change the name of the Textfield.

In OOP, a class should be considered a black box, so it can be reused without really knowing what’s inside. So you would add for instance a computed Property “Text”, which updates TextField1.Text in set, and returns it in Get.

In practice, getting into OOP programming habits gives you a lot of reusability, as you can then drop your containerControl into a new project without having to know the inner workings.

[quote=297167:@Michel Bujardet]All this resorts to OOP good habits. As a matter of principle, one is not supposed to reach inside a class to change values, but to use class methods, interfaces or computed properties do do so.

For instance, if you have a TextField inside a ContainerControl, you can do

ContainerControl1.TextField1.Text = "hello world"

But that could be broken if you change the name of the Textfield.

In OOP, a class should be considered a black box, so it can be reused without really knowing what’s inside. So you would add for instance a computed Property “Text”, which updates TextField1.Text in set, and returns it in Get.

In practice, getting into OOP programming habits gives you a lot of reusability, as you can then drop your containerControl into a new project without having to know the inner workings.[/quote]

I just noticed this thread while I was attempting to access a control within an embedded WebContainer. Specifically, a WebListBox I wanted to populate with rows of data. I see how directly accessing it with dot notation like the TextField above could be a problem if I later changed name of that WebListBox, but wouldn’t this be just as much a problem using a Computed Property that does a Get to the WebListBox? That is, if I later rename that WebListBox, i will break the Computed Property.

Hmm…maybe you mean that if I had many direct references to that WebListBox, they would all break if I renamed that control. But if all those references grabbed the Computed Property instead of the dipping inside the WebContainer, I would only have to edit my Computed Property once and they all would then work again.

You shouldn’t access the WebListBox at all. Instead create an event definition that you will fire from inside the container when it wants data, you then implement that event wherever that container is used to provide the data. Alternatively create a method that you call on the container to give it data, the method then populates the WebListBox.

Basically, if you swapped the WebListBox for some totally different (custom) control, can you still use the container without changing anything?

[quote=349206:@Ian Jones]You shouldn’t access the WebListBox at all. Instead create an event definition that you will fire from inside the container when it wants data, you then implement that event wherever that container is used to provide the data. Alternatively create a method that you call on the container to give it data, the method then populates the WebListBox.

Basically, if you swapped the WebListBox for some totally different (custom) control, can you still use the container without changing anything?[/quote]

So, if I have a method on that container called AddListBoxRow, and it takes a parameter that feeds the AddRow method for that ListBox, that would satisfy this concern? What I was going to do before was to have a method on that container that simply returns the ListBox, so to add a row to it I would use ThatMethod.AddRow.

Hmmm…maybe what you’re saying is to have a more generic method on that container, like GiveMeData, and it would add rows to the ListBox if that’s what’s in there, otherwise it would do something else if I swapped the ListBox out for some other data holding control.

Yep, the latter idea, something generic.

Another option I use often (especially when initiating a control) is to have a computed property for the data and when it is set update the rows in the internal control.

I will probably need to use an interface in this app, so I imagine I’ll need to keep using methods for updating controls within containers.

So, @IanJones. How far do you push this nonPenetration of a container principle? For instance, I have a WebContainer filled with say, 30 fields for data entry. A WebContainer is used here to make it easy to keep the display centered on a WebPage. Because this might one day need an Interface to accommodate mobile as well as desktop browsers, I’ve been assigning a method to the Desktop WebContainer for each WebTextField. So, say, 30 methods to cover 30 TextFields.

But this again would be more like the less generic method I was using to access that list box in that other container. By the logic you’re outlining here, it sounds like you would replace those 30 methods with a single method that branches to handle data entry for the 30 WebTextFields.