DCVARGROUP question

[Cliff Wiernik]

I am attempting to use the DCVARGROUP command as opposed to using aApp and #defines for variables

My command usage is similar to this:

Code: Select all

  DCVARGROUP TO oV NAME mVars   ;
    m_tran_ref      := SPACE(10),       ;
    m_tran_date     := CTOD(''),        ;
    m_tran_amt      := 0,               ;
    m_tran_type     := SPACE(1),        ;
    m_tran_desc     := SPACE(35),       ;
    m_ccompany      := SPACE(60),       ;
    m_cadd1         := SPACE(25),       ;
    m_cadd2         := SPACE(25),       ;
    m_cadd3         := SPACE(39),       ;
    m_caccount      := SPACE(10),       ;
    m_cssn1         := SPACE(9),        ;
    m_cssn2         := SPACE(9),        ;
    m_cphone        := SPACE(10),       ;
    m_cstate        := SPACE(2),        ;
    m_dduedilig     := CTOD(''),        ;
    m_dunclaimed    := CTOD(''),        ;
    m_lduedilprt    := .F.,             ;
                                        ;
    d_lEditmode     := .F.,             ;                                       // Define for TOOL BAR - in edit mode or not
    d_lAddmode      := .F.,             ;                                       //   in add mode
    d_nTabpage      := 0,               ;                                       //   current tab page number
    d_bNextpage     := NIL,             ;                                       //   code block for next page hot key +
    d_bPrevpage     := NIL,             ;                                       //   code block for next page hot key -
    d_cTitle        := '',              ;                                       //   program dialog title
    d_lDisablesave  := .F.,             ;                                       //   flag to disable save button                        
                                        ;
    d_oDialog       := NIL,             ;                                       //   pointer to option dialog screen
                                        ;
    d_oMsgbox       := NIL,             ;
    d_oStatstatic   := NIL,             ;
    d_oStatbar      := NIL,             ;
                                        ;
    d_nSaverecord   := NIL,             ;                                       //   work variable used for current record position
    d_aNtabs        := NIL,             ;                                       //   array containing tab page ordinal number
    d_aOtabs        := NIL,             ;                                       //   array containing tab page object pointers

Instead of passing aApp from main dialog function to called functions, I now pass oV.

I have been using mVars as the NAME in all programs. I just noticed that if I open up two separate dialogs, each in its own thread, that they appear to be colliding. The help file discussion regarding DCVARGROUP is not really documented and the sample file is limited. It would appear that if I use the same NAME in each program, for example I had been using mVars, that this is causing the variables to collide. oV is defined as a LOCAL variable in each dialog.

What is the proper usage of the NAME component and what does it do?

Do I need to be passing the oV local variable between functions?

If I am using a separate local variable, oV, in each thread, is that not keeping them separate or does the NAME used have some effect.

Cliff.

[rdonnay]

I don't see how that is possible.

If oV is a local variable, then it is thread safe.

[Cliff Wiernik]

I looked at the error logs and I think I found the problem. The NAMES used must be unique for the entire applications.

Look at the logs:

Code: Select all

==============================================================================
ERROR LOG of "C:\FCAXBWRK\MAINSL1.EXE" Date: 06/20/2013 13:49:00
------------------------------------------------------------------------------
Xbase++ version     : Xbase++ (R) Version 1.90.355
eXPress++ version   : eXPress++ (c) Version 1.9.258
Operating system    : Windows 7 06.01 Build 07601 Service Pack 1
User                : CAW
Login Name          : CLIFFW
Company             : AFI
Version             : (c) 2005-2012 Aqua Finance Inc(6.13620a Build 19.944)
Database path       : 
Default Directory   : 
Current Directory   : C:\fcaxbwrk\dbf
------------------------------------------------------------------------------
ERROR OBJECT:
------------------------------------------------------------------------------
oError:args         :
          -> VALTYPE: O CLASS: VARGROUP_mVars
oError:canDefault   : N
oError:canRetry     : N
oError:canSubstitute: N
oError:cargo        : NIL
oError:description  : Access to instance-variable not allowed within class-object
oError:filename     : 
oError:genCode      :         31
oError:operation    : d_lEditmode
oError:osCode       :          0
oError:severity     :          2
oError:subCode      :       2241
oError:subSystem    : BASE
oError:thread       :          6
oError:tries        :          0
DAC last message    : 
------------------------------------------------------------------------------
CALLSTACK:
------------------------------------------------------------------------------
Called from TEMPLATE3(188)
Called from _GUIRUN(189)
Called from (B)GUIRUN(139)

Code: Select all

==============================================================================
ERROR LOG of "C:\FCAXBWRK\MAINSL1.EXE" Date: 06/20/2013 13:50:36
------------------------------------------------------------------------------
Xbase++ version     : Xbase++ (R) Version 1.90.355
eXPress++ version   : eXPress++ (c) Version 1.9.258
Operating system    : Windows 7 06.01 Build 07601 Service Pack 1
User                : CAW
Login Name          : CLIFFW
Company             : AFI
Version             : (c) 2005-2012 Aqua Finance Inc(6.13620a Build 19.944)
Database path       : 
Default Directory   : 
Current Directory   : C:\fcaxbwrk\dbf
------------------------------------------------------------------------------
ERROR OBJECT:
------------------------------------------------------------------------------
oError:args         :
          -> VALTYPE: O CLASS: VARGROUP_mVars
oError:canDefault   : N
oError:canRetry     : N
oError:canSubstitute: N
oError:cargo        : NIL
oError:description  : Object has no member with this name
oError:filename     : 
oError:genCode      :         26
oError:operation    : m_tran_ref
oError:osCode       :          0
oError:severity     :          2
oError:subCode      :       2240
oError:subSystem    : BASE
oError:thread       :          6
oError:tries        :          0
DAC last message    : 
------------------------------------------------------------------------------
CALLSTACK:
------------------------------------------------------------------------------
Called from APDUEDIL(258)
Called from _GUIRUN(189)
Called from (B)GUIRUN(139)
------------------------------------------------------------------------------

In the code to create the class object, it is using the NAME value. If the same name is used, which I did because I did not know, it would appear to overwrite the first class define.

You may want to add that to your documentation.

Cliff

[rdonnay]

I hadn't thought about that, but you are correct.

This is a dynamically created class so it looks in memory first to see if it has already been created.

You may want to destroy the class when you are done using it with ClassDestroy().

[Cliff Wiernik]

I implementation of it had the classdestroy(), which is needed, and is in your example. If the dialog is opened and closed and reopened, if you don't do a classdestroy, then the next DCVARGROUP for the dialog will fail. However, it is also important that each dialog or usage of DCVARGROUP has its own unique name. Otherwise, if you have two separate dialogs open, even if in separate threads, the names will cause a conflict.

In my previous testing of this implementation to replace the aApp usage, I had identified the need to use the classdestroy (overlooked it for my new dialog) but had never tried it with two dialogs using DCVARGROUP with the same NAME before. So I had was not aware of this.

Some helpful tips for other users.

Cliff.

[Cliff Wiernik]

One additional questions.

If you use the aApp approach to avoiding the use of private variables, with the corresponding @define variablename aApp[1] and so forth, you can use the compiler warning flags to detect missspellings, etc.

With the use of DCVARGROUP and the definition of instance variables, is there some way to accomplish similar missspellings of instance variable name, other than detecting them at runtime via a generated error.

Cliff.