Hi,
I have started to use the container control in a desktop app I am building.
I have added a number of buttons to the container and added the container to a window. The problem I have is how do I add code within the window to do something when one of the buttons is pressed in the container? I can see I can add code to the button action event within the container itself but that is not where I need the code, I need it in the actual window side of the code.
Thanks
Declare and Raise an event in the container to be used by the programmer (you).
RaiseEvent
You can also raise an event you used to construct the code in the container.
then why did you use a container ? you could have added the buttons directly in the window.
the container if you want to reuse the same in many windows, or many times in one window.
another way to use it is to make an event definition in the container, for example “action_button-1” that you fire when needed.
then this will be available as an event in the windows where you can use it as you wish.
Maybe I have misunderstood the use of the container control.
What I have is a button “New Task” and when it is pressed it opens a window and when that window closes it then updates things on the window. The things it does are different depending on the window the button is one.
What I want to do is have a single “New Task” button that does all the generic stuff and then be able to do the window specific stuff in the action on the window.
What I dont want to have is to repeat the generic code all of the application so I though I could do this using a container control.
Is this the wrong approach?
[quote=438508:@Nathan Wright]Maybe I have misunderstood the use of the container control.
What I have is a button “New Task” and when it is pressed it opens a window and when that window closes it then updates things on the window. The things it does are different depending on the window the button is one.
What I want to do is have a single “New Task” button that does all the generic stuff and then be able to do the window specific stuff in the action on the window.
What I dont want to have is to repeat the generic code all of the application so I though I could do this using a container control.
Is this the wrong approach?[/quote]
Well not really. Implement an event or a property you can use for the window behavior. But it is more convenient to place your shared code in a module ‘Globals’ and add specific code in the action event like:
Sub Action() Handles Action
ExecuteSharedMethod()
... specific code here...
End Sub
@Alexander van der Linden ah ok that makes sense. Can you tell me why you have used a shrared method rather than a standard method in a module, i have read the docs on the two and never really understood the difference between the two types of method.
Thanks for your help.
Ah. You should regard a module like a library of functions that do things that are not bound to or manipulate specific (screen) objects (that is my own interpretation here). Calculations, database access, checks, conversions… whatever…
I think Alexander doesn’t mean shared like what is called shared method. He means like a method that contains the code that is the same for your button.
But - pretty please - no globals methods. That’s a really bad idea. Your button delegates to the model and the model delegates to the actual code.
Me.Too. 
I think if a Method is shared (and so it belongs to the Class, not the instance), calling Self in the shared Method will “link to” the Class instead of the Window for example in which the Method is used. But i may be totally wrong here… 
My general rule is the parent containers know nothing about the internals of the Child container other than Load, Save, and maybe Validate methods. The child container knows nothing about the parent so I implement Event definitions on the Child and RaiseEvent when I need to. Obviously the parent needs to implement those events but it works out well.
If your parent knows (i.e. is coding for) about the contents of the child, or if the child knows the contents of the parent you’re not really using them right. Some will disagree with me I’m sure but the object oriented programming should allow you to use the Child container in multiple places and therefore you have to pass information back and forth with events and an interface.
my opinion is that any event/property etc that belongs to a control embedded in a container control should be exposed via the container control and each internal control should be private. The container should appear and act as a single entity
Yes. Much more succintly put than what I said.
on a side (but related note)
How do you create a property in the container control that would act like the TEXT property of a TextArea (assume the CC contains TA1)
Private Property Text as string
Get
return ta1.text
End Get
Set
ta1.text=value
End Set
End Propertythis would work except for this nagging little error [The name cannot be a keyword]
since now the word “TEXT” is a property name in some places, and a datatype in others
you dont
have to name it something else like Contents
Make it Caption instead of text? It’s a conundrum to be sure. Although I would argue that Text isn’t descriptive enough since the parent shouldn’t know much about the child. So Text is too vague so I would change it to mean something more to an outside observer. Contents might work.
Caption might make sense depending on what control you’re creating this way
If it were something like a list with a header then HeaderCaption might be better
But definitely name it something more descriptive that isnt a keyword
EDIT : bob reminded me to avoid shadowing properties too
In the Container Properties create a variable of type myWindow, which will be Nil initially. When the Window opens, set this container property to Self. Then call the WinSelf.MethodName.
David - I would not do this since that makes this control dependent on what kind of window its in and not portable any more
Adding properties & events to the container works well and encapsulates the guts nicely
I agree with Norman. You’re making an unnecessary dependency. If you use the Event strategy I outlined above you can use this container anywhere and the container needs to know nothing about the parent window/container.
The flip side of this is code that has the window or whatever reaching way down inside a container to set some property or value
By making ALL the controls in a container private it prevents this sort of bad practice that leads to lots of big dependencies and forces you to really think about the API a custom control you make presents to the world - even if it is your own code