[RESOLVED] Procedure Access Levels in Visual Basic-VBForums
Results 1 to 14 of 14

Thread: [RESOLVED] Procedure Access Levels in Visual Basic

  1. #1

    Thread Starter
    Fanatic Member
    Join Date
    Nov 2014
    Posts
    550

    Resolved [RESOLVED] Procedure Access Levels in Visual Basic

    I've been writing code for some time and have a ton of procedures defined as public routines. Moving from one language to another, I have ported these support routines over the years.

    Using these routines in standalone programs has never posed a problem, but now as I'm developing a UserControl, things have changed.

    With UserControls, all of my support routines are accessible to the end user and I'd like to change that.

    Researching VB access levels, I found the modifiers, 'Protected' and 'Friend' but neither work in basic modules.

    I could take all of my routines, concatenate the many files into one large file and bring it into the UserControl file. Then change all of the Public Subs to Private Subs, but I'd hate to go that route, duplicate code to maintain - nasty.

    Any ideas on how to access reusable public code in UserControls without exposing them to the end user?

    Thanks.

  2. #2
    VB-aholic & Lovin' It LaVolpe's Avatar
    Join Date
    Oct 2007
    Location
    Beside Waldo
    Posts
    16,741

    Re: Procedure Access Levels in Visual Basic

    Not sure I fully understand.

    In a usercontrol, are you talking about classes? Code in a bas module isn't public to the user. Can you give us specific examples?
    Insomnia is just a byproduct of, "It can't be done"

    Classics Enthusiast? Here's my 1969 Mustang Mach I Fastback. Her sister '67 Coupe has been adopted

    Newbie? Novice? Bored? Spend a few minutes browsing the FAQ section of the forum.
    Read the HitchHiker's Guide to Getting Help on the Forums.
    Here is the list of TAGs you can use to format your posts
    Here are VB6 Help Files online


    {Alpha Image Control} {Memory Leak FAQ} {Unicode Open/Save Dialog} {Resource Image Viewer/Extractor}
    {VB and DPI Tutorial} {Manifest Creator} {UserControl Button Template} {stdPicture Render Usage}

  3. #3
    PowerPoster
    Join Date
    Feb 2006
    Posts
    17,887

    Re: Procedure Access Levels in Visual Basic

    I think what you are after is what you get by creating an OCX Project.

    The best you can do if you keep everything within a monolith is to set the "hide" attribute on properties and methods:

    Name:  sshot.png
Views: 132
Size:  6.4 KB

  4. #4

    Thread Starter
    Fanatic Member
    Join Date
    Nov 2014
    Posts
    550

    Re: Procedure Access Levels in Visual Basic

    I have routines I used for communications over Serial and Parallel ports in .Bas modules, which are use in a number of my programs. In developing my UserControl, I've made use of these routines by calling the .Bas modules from the UserControl as I would for a standard Exe project.

    All is working, compiles without any problems, but I noticed that once I place the UserControl on a Form, I not only have access to the UC's properties, I also have access to all of my support routines within. One such routine used when working with a Serial Ports called 'Open_Serial_Port', is accessible to the user via; UC.Open_Serial_Port.

    While the UC needs to use the Open_Serial_Port routine, I don't want the user to have direct access to it. Instead of declaring it as a Public Subroutine, I tried using Friend in hopes of still having access to it from the UC, but not from the Form it's sited on. Unfortunately it seems that you can't use the keyword Friend in a .Bas module.

    I can solve the problem by grabbing the code from the Open_Serial_Port.bas module and placing it inside of the UC, and then changing the routine declarations from Public to Private, but then I'll have duplicate code for Open_Serial_Port.bas to maintain along with a bunch of others.


    Name:  Flow_03.JPG
Views: 128
Size:  19.3 KB


    The dashed lines show the access that I don't want, using the UserControls as a bridge to gain access to the support routines.
    Last edited by stuck-n-past; Sep 30th, 2017 at 04:58 PM.

  5. #5
    VB-aholic & Lovin' It LaVolpe's Avatar
    Join Date
    Oct 2007
    Location
    Beside Waldo
    Posts
    16,741

    Re: Procedure Access Levels in Visual Basic

    So, within your UC, you have a public method called Open_Serial_Port that calls the Open_Serial_Port function in the bas module? I'm still confused, I admit.

    For example, my Alpha Image control has a bas module with dozens of public methods. None of those methods are accessible to the user via the UC. In order to expose those, I would need to create a public class that calls the bas methods.

    I am assuming that your UC is its own project, can be compiled as an ocx.
    Insomnia is just a byproduct of, "It can't be done"

    Classics Enthusiast? Here's my 1969 Mustang Mach I Fastback. Her sister '67 Coupe has been adopted

    Newbie? Novice? Bored? Spend a few minutes browsing the FAQ section of the forum.
    Read the HitchHiker's Guide to Getting Help on the Forums.
    Here is the list of TAGs you can use to format your posts
    Here are VB6 Help Files online


    {Alpha Image Control} {Memory Leak FAQ} {Unicode Open/Save Dialog} {Resource Image Viewer/Extractor}
    {VB and DPI Tutorial} {Manifest Creator} {UserControl Button Template} {stdPicture Render Usage}

  6. #6

    Thread Starter
    Fanatic Member
    Join Date
    Nov 2014
    Posts
    550

    Re: Procedure Access Levels in Visual Basic

    Quote Originally Posted by dilettante View Post

    The best you can do if you keep everything within a monolith is to set the "hide" attribute on properties and methods:
    Is it typical to have fairly large UserControls?

  7. #7
    PowerPoster
    Join Date
    Feb 2006
    Posts
    17,887

    Re: Procedure Access Levels in Visual Basic

    Quote Originally Posted by stuck-n-past View Post
    Is it typical to have fairly large UserControls?
    "Large" in what sense?

    I don't see any problem with factoring out code into separate classes used by a UserControl where it makes sense. In some cases you also need a static module too for things like subclassing, callbacks, or worker threads.

    Jamming everything into one module for the sake of having a single file can get cumbersome, hard to maintain, may require ridiculous gyrations, and may limit what you can do.

    The biggest problem with separate OCX and DLL Projects is probably the need for care in maintaining binary compatibility. After that (and along with it) comes the need to manage the associated registry entries.

    To help minimize that you can do careful planning up front and do your initial development and testing with modules within your testbed and unit testing Projects. As it shapes up and you get your object model defined it becomes safer to pull that code out as a separately compiled project and compiled "compatibility reference" binary.

    At that point a lot of these aux modules can be given restricted visibility outside the compiled library.

  8. #8
    Fanatic Member Spooman's Avatar
    Join Date
    Mar 2017
    Posts
    869

    Re: Procedure Access Levels in Visual Basic

    Quote Originally Posted by stuck-n-past View Post
    I have routines I used for communications over Serial and Parallel ports in .Bas modules, which are use in a number of my programs. In developing my UserControl, I've made use of these routines by calling the .Bas modules from the UserControl as I would for a standard Exe project.

    All is working, compiles without any problems, but I noticed that once I place the UserControl on a Form, I not only have access to the UC's properties, I also have access to all of my support routines within. One such routine used when working with a Serial Ports called 'Open_Serial_Port', is accessible to the user via; UC.Open_Serial_Port.

    While the UC needs to use the Open_Serial_Port routine, I don't want the user to have direct access to it. Instead of declaring it as a Public Subroutine, I tried using Friend in hopes of still having access to it from the UC, but not from the Form it's sited on. Unfortunately it seems that you can't use the keyword Friend in a .Bas module.
    I'm a little confused as well, especially as I've never used a UserControl

    Nevertheless, instead of the keyword Friend, what about a public variable Caller?

    1. in the UC, set Caller = "UC" (or something more specific as may apply)
    2. in a routine such as Open_Serial_Port, have a test for Caller
      • if Caller = "UC" .. ok
      • if Not Caller = "UC", exit sub/function


    Does that give you something to work with?

    Spoo

  9. #9
    Fanatic Member
    Join Date
    Feb 2017
    Posts
    644

    Re: Procedure Access Levels in Visual Basic

    There should be no problem.

    All Public Methods in the usercontrol are public to the end-user (aka developer). And that's what is expected.

    All public methods in a bas module wihin the usercontrol's project are not visible to the end-user, but it is globally visible within the usercontrol's project. Perfect.

    What's the problem?

    If you still think that there is a problem, please write a small sample project and attach it here so we can see what you mean.
    Last edited by Eduardo-; Oct 1st, 2017 at 04:09 AM.
    MSDN online for VB6 - Language Reference - Controls Reference
    Download MSDN October 2001: disk 1, 2 and 3

  10. #10

    Thread Starter
    Fanatic Member
    Join Date
    Nov 2014
    Posts
    550

    Re: Procedure Access Levels in Visual Basic

    Sorry for the delay in getting back to the post.

    In general I try and keep 'modules' relatively small and easy to handle for many reasons. One is for simple editing, having to scroll / search through large modules can be time consuming and confusing. Another is re-usability, I've surprised myself at times in that keeping modules on the smaller size I find that they become routines that with little modification can be converted into general use. And one that I feel is the most important is that once a module has been developed / tested, it can be set aside as it were and never touched again. This can help prevent it from accidentally having a typo introduced or some other kind of error unintentionally left behind.

    With that said, and UserControls being somewhat of a new animal for me, it's not so easy to keep things modular with these creatures. One common compile error that comes up often when trying to keep sections of code in separate modules is as follows:

    Code:
    Enum types defined in standard modules or private 
    classes cannot be used in public object modules as 
    parameters or return types for public procedures, as 
    public data members, or as fields of public user defined 
    types.
    This has caused me to move code out from a UserControl and into a .Bas Module and then back again on more then one occasion when it wont compile.

    I've tried grouping similar .Bas files into Class Modules and then playing around with Instancing set to GlobalMultiUse and PublicNotCreatable to find the proper combination of public / private code and data.

    To be quite honest I'm rather confused right now as I'm seeing things that appear public that should be private and vice versa.
    Last edited by stuck-n-past; Oct 2nd, 2017 at 07:11 PM.

  11. #11
    VB-aholic & Lovin' It LaVolpe's Avatar
    Join Date
    Oct 2007
    Location
    Beside Waldo
    Posts
    16,741

    Re: Procedure Access Levels in Visual Basic

    Classes
    GlobalMultiUse = public to the customer.
    good place to put constants, UDTs, properties and functions for the customer
    items in this class are considered usercontrol-wide, not per usercontrol
    PublicNotCreatible = can be referenced but not created
    Typically returned as a class/uc function
    MultiUse = can be created using the New keyword
    Private = not visible to the customer
    meant for uc-only
    BAS modules not visible to the customer

    Sounds like you may be seeing methods you added to a class with the instancing of GlobalMultiUse or as a public method added to your usercontrol.
    Last edited by LaVolpe; Oct 2nd, 2017 at 04:44 PM.
    Insomnia is just a byproduct of, "It can't be done"

    Classics Enthusiast? Here's my 1969 Mustang Mach I Fastback. Her sister '67 Coupe has been adopted

    Newbie? Novice? Bored? Spend a few minutes browsing the FAQ section of the forum.
    Read the HitchHiker's Guide to Getting Help on the Forums.
    Here is the list of TAGs you can use to format your posts
    Here are VB6 Help Files online


    {Alpha Image Control} {Memory Leak FAQ} {Unicode Open/Save Dialog} {Resource Image Viewer/Extractor}
    {VB and DPI Tutorial} {Manifest Creator} {UserControl Button Template} {stdPicture Render Usage}

  12. #12
    PowerPoster
    Join Date
    Feb 2006
    Posts
    17,887

    Re: Procedure Access Levels in Visual Basic

    "Friend" allows visibility within a compiled module (code module as in hModule, a DLL, EXE, etc. not a source module) between classes (including UserControl, Form, Class, etc.). "Friend" members are not part of a class' COM interface.

    "Public" allows visibility between compiled modules. "Public" also is used with a second meaning within static .BAS modules where it is treated more like "Friend" but also applies to data as well as properties and methods. "Global" is an old synonym for this usage of "Public," retained for backwards compatibility.

  13. #13

    Thread Starter
    Fanatic Member
    Join Date
    Nov 2014
    Posts
    550

    Re: Procedure Access Levels in Visual Basic

    Hey guys thanks for the help with VB's access level keywords and settings, it's helped in clarifying some of my confusion.

    This project is without a doubt the largest project I've had to date, between the Communications back-end coupled with the extensive GUI front-end, and all of the guts in the middle, well it's a monster.

    Till now testing has been done separately, Comms & GUI. Now that I'm merging the parts together I'm finding a few hiccups including private and public issues. I'm going to take another close look checking for any routines living in the wrong modules, as I have moved quite a few around from file to file during the merge. I can see where I might have accidentally moved a 'private' routine to a module with it's instancing set to GlobalMultiUse.

    Thanks.

  14. #14

    Thread Starter
    Fanatic Member
    Join Date
    Nov 2014
    Posts
    550

    Re: Procedure Access Levels in Visual Basic

    Without really changing any code, I have reorganized Bas files and my Class Modules after having a better understanding of VB's data and routine access levels.

    Now what's supposed to be private is indeed private, thanks for the help.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  



Featured


Click Here to Expand Forum to Full Width

Survey posted by VBForums.