Results 1 to 19 of 19

Thread: Public variables mystery. *RESOLVED*

  1. #1

    Thread Starter
    Member
    Join Date
    May 2004
    Location
    Huntington WV
    Posts
    49

    Resolved Public variables mystery. *RESOLVED*

    I have a problem with my program that has developed into a real mystery. So for you coding Sherlock Homes types I will provide as much clues that I can.

    My program has 5 forms. They are listed below;
    frmMain – this form has a dbGrid that displays records in the datafile.
    frmEdit – this form is for editing a record in my datafile.
    frmAddNew – this form is for adding new records to my datafile.
    frmPrintMenu – this is a menu of print and preview options.
    frmPrintcard – this is a output form to be printed or previewed.

    I also have a Module called GlobalModule. This module holds my Public Variables. In this module I have the following public variables defined.

    Code:
    Public gsRecordID As String
    Public gsCDNumber As String
    Public gsCDTitle As String
    Public gsCDCompany As String
    Public gsCDVersion As String
    Public gsCDSerialNumber As String
    Public gsCDKey As String
    Public gsCDType As String
    Public gsCDDescription As String
    Public gsCDNotes As String
    Public gsDatabasePassword As String
    Now here is the problem.
    When I open the frmMain and select from the menu to add a record using frmAddNew it opens the form frmAddNew and shows the text fields black. I add my record and save it without any problem. Then from the frmMain form I click on the record that I just saved and it then opens the frmEdit form and displays the data. Still no problem so far. On the frmEdit form I click on a button to print. This button contains the following code and calls 2 sub procedures.

    Code:
    Private Sub cmdPrintMenu_Click()
        ClearData
        CollectFormData
        frmCDPrintMenu.Show (1) '(1) makes the form Modal
    End Sub
    
    Private Sub CollectFormData()
    
            gsCDNumber = lblCDNumber.Caption
            gsCDTitle = txtName.Text
            gsCDCompany = txtCompany.Text
            gsCDVersion = txtVersion.Text
            gsCDSerialNumber = txtSerialNumber.Text
            gsCDKey = txtKey.Text
            gsCDDescription = txtDescription.Text
            gsCDNotes = txtNotes.Text
    
    
    End Sub
    
    Private Sub ClearData()
            gsCDNumber = ""
            gsCDTitle = ""
            gsCDCompany = ""
            gsCDVersion = ""
            gsCDSerialNumber = ""
            gsCDKey = ""
            gsCDDescription = ""
            gsCDNotes = ""
    End Sub
    Now, the program displays the form frmPrintMenu which only has a button on it to preview or print a form. Here is the code for the preview button.

    Code:
    Private Sub cmdPreviewCDCard_Click()
    Unload Me
    frmPrintCard.Show
    End Sub
    One the form frmPrintCard I have a number of text boxes that I set the properties in code. I have shown one of the text boxes code below.
    Code:
    'CD TITLE
    With lblCDTitle
        .Left = "4050"
        .Top = "400"
        .Width = "7200"
        .AutoSize = True
        .Alignment = 0
        .Caption = gsCDTitle
        .Font = "MS Sans Serif"
        .FontSize = "12"
        .FontBold = True
    End With
    As you can see I am displaying the data that I passed to the globalmodule Public Variable gsCDTitle in the frmEdit form in the Print button code.

    So I first clear the Public variable string, then I pass the values in the text fields in the frmEdit to the Public Variables and then they are passed to the frmPrintCard form. However, this is what happens. When I enter my first record and save it and go to the frmMain and click on the record it displays in the frmEdit form correctly. I then can click on the PRINT button and preview or print the record fine. However when I enter the second record and go to the frmMain and click on the record, it displays correctly in frmEdit as expected. Then when I click on the PRINT button, it displays the previous record information. I then go back to the frmMain form again, click on the same record, view it correctly in the frmEdit form and this time when I click on the PRINT button, the correct record displays. I can not understand if I have the correct data in the frmEdit form and I am clearing the Public Variables and then populating them by passing the text that is being displayed on the form to the Public variable, why would it still have the old data in the frmPrintCard form? Also, why does it display correctly when I go through the same process again? This is consistent. I add a record, save it, preview it, then preview it again and the second time its correct.

    I know this was a long explanation, but I thought the more information to this problem the better. Thanks all of you for your help in the past and on this problem.

    Mike

    9/30/04 ----------- SOLUTION

    Well, I took a break, had some “Tazo® Chai Tea Latte” at Starbucks and re-thought the problem. When the caffeine hit my bloodstream, I came up with the answer. Push the variables to the form before opening the form. Here is the code that solved the problem.

    Code:
    Private Sub Populate_frmPrintCard()
            With frmPrintCard
            .lblBarCode.Caption = "*" & lblCDNumber.Caption & "*"
            .lblBarCodeText.Caption = lblCDNumber.Caption
            .lblCDTitle.Caption = txtName.Text
            .lblCDCompany.Caption = txtCompany.Text
            .lblCDVersion.Caption = "Version: " & txtVersion.Text
            .lblCDSerialNumber.Caption = "Serial Number: " & txtSerialNumber.Text
            .lblCDKey.Caption = "Key: " & txtKey.Text
            .lblCDDescription.Caption = txtDescription.Text
            .lblNotes.Text = txtNotes.Text
            End With
    End Sub
    This made the code simpler and it never failed in testing. This is really what I love about VB and programming. Not that I am a good programmer by any since of the word, but I do love being able to work out a problem on my own and that if one way does not work, then try another. Thanks again for everyone’s input and comments. The project would not have been possible if it was not for vbforums.com

    Mike
    Last edited by MIKEADKINS; Oct 1st, 2004 at 02:10 PM.

  2. #2
    PowerPoster RhinoBull's Avatar
    Join Date
    Mar 2004
    Location
    New Amsterdam
    Posts
    24,135
    Can you attach your project, please.

  3. #3
    I'm about to be a PowerPoster! kleinma's Avatar
    Join Date
    Nov 2001
    Location
    NJ - USA (Near NYC)
    Posts
    23,383
    debugging is your friend. Set a break point (or even a watch on the variable) and step through your code. You will find your problem pretty quickly, and I bet it will be something you will think is stupid once you find it.

  4. #4
    PowerPoster Dave Sell's Avatar
    Join Date
    Mar 2004
    Location
    /dev/null
    Posts
    2,961
    There is no mystery here. Global variables are a bad idea and can lead to insurmountable problems.

    I've said it before, and I'll say it again: don't use global variables!

    That's not what those modules are there for!

    *subscribe*
    Last edited by Dave Sell; Sep 28th, 2004 at 08:46 PM.

  5. #5
    I'm about to be a PowerPoster! kleinma's Avatar
    Join Date
    Nov 2001
    Location
    NJ - USA (Near NYC)
    Posts
    23,383
    yeah you should make a UDT or class

  6. #6
    PowerPoster RhinoBull's Avatar
    Join Date
    Mar 2004
    Location
    New Amsterdam
    Posts
    24,135
    Originally posted by Dave Sell
    There is no mystery here. Global variables are a bad idea and can lead to insurmountable problems.

    I've said it before, and I'll say it again: don't use global variables!

    That's not what those modules are there for!

    *subscribe*
    No offence, please, but this is one of the most rediculous opinions I've ever heard.

  7. #7
    Frenzied Member David.Poundall's Avatar
    Join Date
    Sep 2002
    Location
    Robin Hood Land
    Posts
    1,457
    Seconded. UDT's bring in thir own VB baggage.
    David

    Learn the Rules so that you know how to break them properly.

    Printing dll dBTools MZTools Winsock API WinsockVB More Winsock SGrid2 MSChart Mail2Web

    If you have found this thread useful then read this

  8. #8
    PowerPoster Dave Sell's Avatar
    Join Date
    Mar 2004
    Location
    /dev/null
    Posts
    2,961
    Originally posted by RhinoBull
    No offence, please, but this is one of the most rediculous opinions I've ever heard.
    OK, if it really is ridiculous then you should be able to explain clearly why exactly my statement is ridiculous.

  9. #9
    PowerPoster RhinoBull's Avatar
    Join Date
    Mar 2004
    Location
    New Amsterdam
    Posts
    24,135
    OK, if you don't know ...
    Public vars are repository for GLOBAL data that needs to be kept throughout the execution. In your "case" you'll either need to keep that data using local vars or properties directly on the form which means entire form object must be in the memory (and this is already very bad design by far). You may create a PUBLIC custom property for some or every form but this would be almost identical to having public vars anyway. Another way for you could be to store some global data in some table or ascii file or xml doc or excel or whatever but this means you'll be forced to create unnecessary object to access and read your data ... That could become a very huge overhead ...

    Something for you to think about.
    Do more research on how to properly use PUBLIC (global) variables.

    My best regards.

  10. #10
    PowerPoster Dave Sell's Avatar
    Join Date
    Mar 2004
    Location
    /dev/null
    Posts
    2,961
    Originally posted by RhinoBull
    OK, if you don't know ...
    Public vars are repository for GLOBAL data that needs to be kept throughout the execution. In your "case" you'll either need to keep that data using local vars or properties directly on the form which means entire form object must be in the memory (and this is already very bad design by far). You may create a PUBLIC custom property for some or every form but this would be almost identical to having public vars anyway. Another way for you could be to store some global data in some table or ascii file or xml doc or excel or whatever but this means you'll be forced to create unnecessary object to access and read your data ... That could become a very huge overhead ...

    Something for you to think about.
    Do more research on how to properly use PUBLIC (global) variables.

    My best regards.
    So you are assuming I do not know what global variables are, and I do not know why people use them?

    Trust me I've been programming for over a decade I'm currently an OO software architect, and wrote my first program 20 years ago. I know all too well about Global variables and when and where they should and should not be used.

    And my assertion is that Global/Public variables should never be placed in a Module container in a VB6 project of any kind for any reason at any time.

    I am coming from a pure OO approach which will be broken by that behavior. Don't be so quick to jump to conclusions about me just because you and I don't see eye to eye.

    Yes my statements are controversial, but not meant to be inflamatory. I have a great interest in debating this lets just keep it civil and refrain from hurling insults.

  11. #11
    PowerPoster RhinoBull's Avatar
    Join Date
    Mar 2004
    Location
    New Amsterdam
    Posts
    24,135
    What you reffer to as "OO approach" can very abusive when misused especially in VB.Classic
    Although, it doesn't really matter how many years you have been in this business but it certaily does matter what's on your mind (programming wise of course ) now.

    I personally don't find your posts inflamatory in any way and also hope that this interesting debate will not get off hand.

    EDIT: You may PM me if you wish to continue in private.

    Cheers
    Last edited by RhinoBull; Oct 1st, 2004 at 09:10 AM.

  12. #12
    Frenzied Member David.Poundall's Avatar
    Join Date
    Sep 2002
    Location
    Robin Hood Land
    Posts
    1,457
    OK for what it is worth here is a less technical viewpoint...

    For my part I have been programming VB for only four years and admitedly am only just (much belatedly) geting into using classes - hence I have been a heavy globals user. Having said that I have found that tightly written code using Globals is simpler to visualise and code (which may be an applications thing).

    Admittedly most of my applications have been stand alone, but the visualisation thing also makes my code easier to maintain.


    :mike:
    David

    Learn the Rules so that you know how to break them properly.

    Printing dll dBTools MZTools Winsock API WinsockVB More Winsock SGrid2 MSChart Mail2Web

    If you have found this thread useful then read this

  13. #13
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    35,245
    If you are heavily into OO, globals are bad. If you are heavily into performance, following too closely to any particular design style (including OO) is bad. There are times in games when globals are simply faster because truly encapsulating access can come at a cost...unless you can inline correctly, but you can't in VB.

    I have never favored slavishly adhering to any design paradigm. VB6 is not OO, don't make it so, it will only slow things down.

    However, you can use modules to achieve the underlying purpose behind OO of encapsulation, but you can't do any other OO stuff with them.

    As for the main topic of this thread: I agree with Kleinma (of course) debugging is your friend, especially in this case. This problem has an easy answer if you step through the code.
    My usual boring signature: Nothing

  14. #14
    PowerPoster RhinoBull's Avatar
    Join Date
    Mar 2004
    Location
    New Amsterdam
    Posts
    24,135
    Originally posted by Shaggy Hiker
    ... As for the main topic of this thread: I agree with Kleinma (of course) debugging is your friend, especially in this case. This problem has an easy answer if you step through the code.
    Indeed.

  15. #15

    Thread Starter
    Member
    Join Date
    May 2004
    Location
    Huntington WV
    Posts
    49

    WOW - What a thread I started.

    Hay guys, play nice.

    I did find a simple solution as explained in my original thread. And I did not mean to start such a thread about public variables. But I am trying to learn. I do not have the experience or wisdom that most of you seasoned programmers do. So please be gentle. For those who are also reading this thread and trying to learn, what I was trying to do was pass information from one form to another. In VB 5 you could define a Public Variable and it would pass between forms. Not so in VB6. What I remember from my VB classes was to define Public Variables in a Global Module. Now from this tread I understand that this is bad programming practices and that it is undependable. Well, I can contest to the fact that it is undependable but I am still not sure why. It would appear that if I cleared the variable and then passed a text string into the variable it should retain the new information. I am not familiar with defining classes and such, but in this case it did seem like swatting a fly with an elephant. Thanks again for your comments and help. Mike

  16. #16
    PowerPoster RhinoBull's Avatar
    Join Date
    Mar 2004
    Location
    New Amsterdam
    Posts
    24,135

    Re: WOW - What a thread I started.

    Originally posted by MIKEADKINS
    ... In VB 5 you could define a Public Variable and it would pass between forms. Not so in VB6. ...
    Why not? It might not the best way arround but it surely possible in all versions.
    Best way to pass values between forms is to use Form's custom property but it also has to be Public. Advantage of such technic is huge: every time you need to read/write to any of form's custom properties - form itself won't be loaded into a memory.
    On the other hand if you need to refer to any control on the form from anywhere in your project that form will be immediately loaded and will remain in such state until unloaded or entire application is ended. This is also a good way for memory leak.

    So, if you're looking for better way to pass value from to form then I'd recommend to start using Custom Properties.

    Let me know if you need more assistance.

    Best regards, RB.

  17. #17
    PowerPoster Dave Sell's Avatar
    Join Date
    Mar 2004
    Location
    /dev/null
    Posts
    2,961

    Re: Re: WOW - What a thread I started.

    Originally posted by RhinoBull
    Why not? It might not the best way arround but it surely possible in all versions.
    Best way to pass values between forms is to use Form's custom property but it also has to be Public. Advantage of such technic is huge: every time you need to read/write to any of form's custom properties - form itself won't be loaded into a memory.
    On the other hand if you need to refer to any control on the form from anywhere in your project that form will be immediately loaded and will remain in such state until unloaded or entire application is ended. This is also a good way for memory leak.

    So, if you're looking for better way to pass value from to form then I'd recommend to start using Custom Properties.

    Let me know if you need more assistance.

    Best regards, RB.
    I agree completely with Rhino on using Public Properties to pass data between forms.

    Check out this older post where I give sample code of what that could look like:

    http://www.vbforums.com/showthread.p...hreadid=305088

  18. #18
    I'm about to be a PowerPoster! kleinma's Avatar
    Join Date
    Nov 2001
    Location
    NJ - USA (Near NYC)
    Posts
    23,383

    Re: WOW - What a thread I started.

    honestly, there is nothing wrong with global variables other than they are too hard for US HUMANS to keep track of... that is why they are frowned upon.. because you start using the same variable all over your app, and you forget that it is accessed in this one spot, and its screwing your app all up and you don't know why.. that is why localizing things is good practice, and global is not. With computers now, its not like you are going to see performance differences using a bunch of global vars or anything... its all about keeping your projects easy to maintain from a coding standpoint..

    so we can all agree there are several ways to do what you want to do, UDT, Class, public vars, passing vars via properties...

    they can all yield the same exact results.. its how difficult you want to make it on yourself as a programmer as to which one you choose.

  19. #19
    PowerPoster Dave Sell's Avatar
    Join Date
    Mar 2004
    Location
    /dev/null
    Posts
    2,961
    Right on!

Posting Permissions

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



Click Here to Expand Forum to Full Width