Create Control At Runtime?

[Eloff]

How can I create a new picturebox on a form at runtime? Surely this is possible?

 

Any input is appreciated.

-Dan

[Guest mutant]

Hi.

Try this:

 

Dim newctrl As New PictureBox() 'dim the Picturebox
Dim pt As Point 'Dim the point to use for location
pt.X = 200 'point x
pt.Y = 200 'point y
Me.Controls.Add(newctrl) 'Add to controls and show on the form.
newctrl.Location = pt 'Set the location

[Eloff]

Hey it worked! I was sure I've already tried the me.controls.add before so I was very surprised when I actually saw my image on the form! Thanks mate.

 

Dan

[Eloff]

As a matter of interest, how would you handle events, like a mouse click on a picturebox that's been created at runtime?

[divil]

You have to wire up the events at runtime. In VB, you use AddHandler to do this. In C#, you add a new EventHandler (or derivative) to the event.

[Guest mutant]

Look at this example, it should help you:

 

Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
       Dim newctrl As New PictureBox()
       Me.Controls.Add(newctrl)
       AddHandler newctrl.Click, AddressOf handler
End Sub

Private Sub handler(ByVal sender As Object, ByVal e As System.EventArgs) 'This sub must have arguments
'that correspond to the event, for ex. click requires sender as object and e as system.eventargs as you see
       MsgBox("hi")
End Sub

[Robby]

mutant, just to correct the typo.

 

this line should read....

AddHandler newctrl.Click, AddressOf [color=red]handler[/color]

[Guest mutant]

I edited it, thanks for pointing that out.

[Eloff]

That works great, but what happens when you have 10 controls created at runtime? how will you know which one was clicked? Or do you need a seperate handler for every control?

 

Thanks!

 

Dan

[NicoVB]

It depends on what you want to do with it. If your other controls have to do the same as the first one, you should refer all your controls to that handle. If you want to do something complete different with the other controls you have to build each time a different handler.

[Guest mutant]

You have to check what is the sender:

 

Dim picbox1 As New PictureBox()
Dim picbox2 As New PictureBox()

Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
Me.Controls.Add(picbox1)
Me.Controls.Add(picbox2)
AddHandler picbox1.Click, AddressOf handler
AddHandler picbox2.Click, AddressOf handler

End Sub

Private Sub handler(ByVal sender As Object, ByVal e As System.EventArgs)
If sender Is picbox1 Then
  MessageBox.Show("Picbox1 was clicked")
ElseIf sender Is picbox2 Then
   MessageBox.Show("Picbox2 was clicked")
End If
End Sub

[Eloff]

Got everything working fine now. Thanks a lot for the help guys.

[steved]

Referring to the case where you have 8 (or possibly more) controls on your form and you want to programatically handle events from each one:

 

Visual Studio 2003 and the new .NET framework will be capable of handling control arrays. This means you can manipulate controls the old VB6 way, with indexed addressing, rather than using collections all the time. (In terms of VS2002, it was a really stupid move on the development team's part to leave control arrays out. But I digress.)

 

If you don't care about the ability to manipulate controls at all using the IDE, you CAN create control arrays in VS2002 (I've done it), as far as C# is concerned. (I haven't tested this with VB.net.) It is kind of a pain, though, since using the designer within the IDE will destroy any of the array code you stuck in that section marked "do not modify the contents of this method with the code editor." :D

 

.steve

[divil]

I'm pretty sure vs.net 2003 won't have control arrays. They would require a fundamental change to the way designers, sites and serializers work in the framework.

[Heiko]

The idea of a control array sounds very un-OO to me in the first place.

[steved]

I was recently (2 weeks ago) at a Visual Studio 2003 launch. Aside from Managed C++ coming into the full light of the IDE (we supposedly get all the fun drag-and-drop functionality that C#/VB give us), one of the major highlighted features was control arrays. We were told that control arrays were originally left out for 2 reasons:

 

1) Time constrains on the vs 2002 project

2) The VS 2002 team didn't feel they were necessary, since you could get most equivalent functionality from collections

 

Personally, I would really like to see them in Visual Studio. There are two major containers I want when I'm dealing with my data: arrays and lists. A collection is just a specialized list, and that's not good enough on its own.

 

divil: Yes, control arrays will require some drastic changes. That would be the whole "time limitation" thing for VS 2002. :)

 

Heiko: I'm not really sure how arrays are un-OO. There's nothing about arrays, in general, that makes them OO or non-OO. They're simply a way of implementing your data. Since a control is just a boring old object instantiation, there's no reason to prevent people from lumping them together in arrays.

 

I'm not sure if you guys have heard differently since the Canada VS2003 launch. If you have, let me know. If control arrays are gone, the .NET team is getting a nasty letter. ;)

[Cywizz]

Hi steved..

 

Personally, I would really like to see them in Visual Studio. There are two major containers I want when I'm dealing with my data: arrays and lists. A collection is just a specialized list, and that's not good enough on its own.

 

Is there any functionlity missing in the current event/delegate driven architecture that you feel you will gain in using control collections again?

[steved]

Cywizz,

 

I am already using control collections, as this is the only way to group and organize controls in vs 2002. What I want is control arrays. To my knowledge, they will be included in vs 2003 (unless the vs team decided to give them the heave-ho at the last minute).

 

I'm not really sure I understand your question: Comparing control arrays/collections to the delegate/event architecture is completely bizarre. The former is a method of grouping (and possibly enumerating) controls in a logical manner, the latter deals with events fired by activity surrounding a particular control or object.

 

Here is the straight poop:

 

We have all 4 things: control collections, arrays, delegates, and a strong event structure.

 

With Visual Studio 2002, we're missing control array functionality in the designer only. They're perfectly programmable. If you're writing your apps in Notepad or vi (a la mono, perhaps?), you're free to create all the control arrays you want, since the Visual Studio designer interface won't have a chance to squash them.

 

Hope this clears things up.

 

.steve

[Cywizz]

steved..

My mistake, I should have asked why array's and not collections as stated.

 

You can have multipal controls hooking up to one event (as you do with a control array). Thats the reason I've mentioned events and delegates. Events do not just have to cater for only one control or object (Runtime use)

 

As for design time, maybe, (although I think you can already use it in vs2002 if I'm not mistaking, adding it to your toolbox). But you will in general (or I have) only use control arrays at runtime (dynamically)

 

Cheers...

[steved]

Herein lies the issue. :)

 

I often have a single function dealing with multiple controls. And though I do love having this ability, I still don't see what it has to do with control arrays or collections, since hooking multiple objects into a single event handler does not require that those objects be in any sort of structure. I'm not even all that familiar with control arrays in VB6, but I guess there might be some relation between classic VB control arrays and the delegate framework? This isn't what I'm trying to achieve, if that's what you're asking.

 

I only want control arrays so I can address controls by an indexed value. This is far preferable to identifying them by tag and looping through a collection until I find the tag I want. (Which was Microsoft's recommendation for addressing "indexed" controls in vs 2002, I believe.)

 

You're right: You can do runtime control arrays in visual studio, and they work fine. You can also do design time control arrays outside of visual studio. However, when I'm designing a piece of software as a contractor, I want to know that my choice of engineering strategy doesn't baffle the guy who's left to maintain my software. And since I baffle people at the best of times ;), using runtime control arrays probably isn't the best choice. (Not to mention it's sloppy, from a design perspective.)

 

.steve

[Nerseus]

I've used control arrays at design time and runtime. The only thing missing is control arrays at design time. Their benefit? Being able to set known indexes at design time and position them to their exact location. Then you can write looping code against those controls easily. To mimic this in VS.NET, you have to create control arrays at run time and position them manually - not that hard, but nearly as convenient as using the designer. If you already wanted run-time control arrays then you're in luck as they're just as easy in .NET as VB6 and lower.

 

-nerseus

[Cywizz]

I can see where you coming from.... and going :)

 

Have you tried the option of extending on a collection, and creating your own implementation. (e.g. creating a strongly typed collection with different indexers)

 

BTW ... I heard that vs2003 will have new strongly typed collections/array's , (I can't remember what they called it) which make sense catering for control array's I suppose.... Chow

[UCM]

Having control arrays would have some benifit for developers...

 

When I first started messing around with visual basic many years ago, my first idea was to create a tetris like game using many image objects accessed by an index number on each image...

 

This allowed for an easy way of changing the squares on the tetris board...

 

If this feature were added to .NET then it would make accessing multiple objects with just a line of code or two much easier...

 

If not, I suppose one way around it would be to use a collection of object references where each one would reference every object you needed to access in a series of objects... Although that would take a considerably longer amount of time to code...

 

If Microsoft adds that feature then great! otherwise, there's always away around things...

[steved]

I haven't tried extending any collection classes, but that would be really cool if someone did. :) Unfortunately, most of my .NET time is here at work where I don't have the luxury of programming such things for fun. But if someone else tries it, I'd be willing to donate a half hour a day to see if it could be done (pseudo-SourceForge style).

 

I doubt the end result would be very useful, but it would be a fun experience, I think.