Wrox Programmer Forums
|
BOOK: Visual Basic 2005 Programmer's Reference
This is the forum to discuss the Wrox book Visual Basic 2005 Programmer's Reference by Rod Stephens; ISBN: 9780764571985
Welcome to the p2p.wrox.com Forums.

You are currently viewing the BOOK: Visual Basic 2005 Programmer's Reference section of the Wrox Programmer to Programmer discussions. This is a community of software programmers and website developers including Wrox book authors and readers. New member registration was closed in 2019. New posts were shut off and the site was archived into this static format as of October 1, 2020. If you require technical support for a Wrox book please contact http://hub.wiley.com
 
Old January 16th, 2007, 11:07 AM
Authorized User
 
Join Date: Dec 2006
Posts: 39
Thanks: 0
Thanked 0 Times in 0 Posts
Default Setting controls from other modules

I have the same controls on a number of forms, and I have a subroutine to set their properties in a separate module. I call the subroutine from the form - e.g.

setItems(me)

and in the module,
   sub setItems(frm as form)
      with frm
          .label1.text="fred"
etc

This gives an error - I can fix it by changing the "Friend WithEvents label1" statement in the form's designer to "Public WithEvents label1"

Is this good practice to modify the designer? Is there a better way?

 
Old January 17th, 2007, 11:02 AM
Rod Stephens's Avatar
Wrox Author
 
Join Date: Jan 2006
Posts: 647
Thanks: 2
Thanked 96 Times in 95 Posts
Default

Well, this shouldn't give you an error if the module is in the same project as the form. The Friend keyword should make the controls available in any piece of code within the assembly. You would only need to change it if the subroutine were in a separate assembly.

The way this code snippet is written, it shouldn't know what label1 is because the parameter to the routine is a generic Form. You would need to pass in a more specific Form1 or frmWhatever for it to know about the exact controls on it.

But in general, I wouldn't modify the designer-generated code. If you edit the form in the designer, it's likely to get confused and possibly change it back to Friend. It is certainly not where someone else (or possibly you later) would think to look if there were an obscure bug involving that code.

I would think about some other way to pass the controls to the subroutine. For example, have the form provide public property procedures to return the key controls. Or pass the form's Controls collection to the routine. Then the routine can loop through the collection to manipulate the controls. Or it can access a control by name like this:

    Public Sub SetItems(ByVal ctls As System.Windows.Forms.Control.ControlCollection)
        ctls("Label1").Text = "Fred"
    End Sub


Rod
RodStephens@vb-helper.com
Author of "Visual Basic 2005 Programmer's Reference"
http://www.vb-helper.com/vb_prog_ref.htm

Sign up for the free VB Helper Newsletters at http://www.vb-helper.com/newsletter.html
 
Old January 17th, 2007, 02:13 PM
Authorized User
 
Join Date: Dec 2006
Posts: 39
Thanks: 0
Thanked 0 Times in 0 Posts
Default

Thanks - passing the controls collection worked fine once I realised that controls in a panel or groupbox do not appear directly in the forms controls collection.

Oddly, ToolTips do not appear either.

 
Old January 18th, 2007, 10:35 AM
Rod Stephens's Avatar
Wrox Author
 
Join Date: Jan 2006
Posts: 647
Thanks: 2
Thanked 96 Times in 95 Posts
Default

Nowadays the Controls collection only includes the immediate children of a control and you have to search their children for other descendants.

ToolTips and other non-control components seem to be in the form's Components collection, although they are stored there as type IComponent and that doesn't have many properties (not even Name).

If you need to find specific controls, you may be better off either exposing them through public properties or giving the form a new collection, perhaps StandardControls. You can put references to the controls that you need to modify in there and pass that to the subroutine. It feels clumsier but more certain.


Rod
RodStephens@vb-helper.com
Author of "Visual Basic 2005 Programmer's Reference"
http://www.vb-helper.com/vb_prog_ref.htm

Sign up for the free VB Helper Newsletters at http://www.vb-helper.com/newsletter.html





Similar Threads
Thread Thread Starter Forum Replies Last Post
Using modules drmacy BOOK: Beginning ASP.NET 2.0 BOOK VB ISBN: 978-0-7645-8850-1; C# ISBN: 978-0-470-04258-8 0 September 21st, 2007 10:39 AM
Running Modules Brendan Bartley Access 2 December 28th, 2006 11:05 AM
Class modules lallemantdo Excel VBA 4 August 24th, 2005 08:35 PM
Missing Modules? Code-a-text BOOK: ASP.NET Website Programming Problem-Design-Solution 2 November 10th, 2004 10:35 PM
Removal of modules slgknjn Excel VBA 0 September 24th, 2004 12:35 AM





Powered by vBulletin®
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
Copyright (c) 2020 John Wiley & Sons, Inc.