Topic: Can't make my vars local?

[mkweaver]

Has anyone ever experienced this before?  I can't seem to make my variables local.

The declaration is thus:

Code: [Select]

(defun ReplaceThisInsertion(ReplacingBlockName
    BlockBeingReplaced
    AttMap
    /
    a
    attnew
    attold
    attsnew
    attsold
    objnew
    ospace
    prop
    propertyname
    )and when I check it in the vlisp IDE I get this:
; === Top statistic:
; Global variables: (A ATTMAP ATTNEW ATTOLD ATTSOLD BLOCKBEINGREPLACED OBJNEW PROP PROPERTYNAME)
; Function definition (with number of arguments): ((LISTATTS . 1) (REPLACETHISINSERTION . 3))
; Check done.


Along with the variables declared as local going global, two of my three arguments are being listed as global variables as well.  Notice also, that not all of the locally declared variables end up as globals.

What am I missing here?  Why would some of the variables I have declared locally end up as global variables?  And why would some of my formal arguments end up as global variables?  Suggestions gladly considered.

Mike Weaver

[Jeff_M]

Odd, this is what I get:

; === Top statistic:
; Function definition (with number of arguments): ((REPLACETHISINSERTION . 3))
; Check done.

Maybe a setting in VLIDE? (I couldn't find one in a quick glance)

[SomeCallMeDave]

I have seen this happen when using the arguments in a function defined within another function

Code: [Select]

(defun testVars (pArg1 pArg2 / Test1 Test2 Test3)
    (defun InnerFoo ()
         (setq testThis (+ pArg1 pArg2))

    );defun innerfoo
    (setq Test1 (+ pArg1 pArg2)
  Test2 (+ pArg1 2)
  Test3 (+ pArg2 3)
    )
   (princ (strcat "\nTest1 = " (itoa Test1)))
   (princ (strcat "\nTest2 = " (itoa Test2)))
   (princ (strcat "\nTest3 = " (itoa Test3)))
   (prin1)
)



Code: [Select]

; === Top statistic:
; Global variables: (PARG1 PARG2 TESTTHIS)
; Function definition (with number of arguments): ((INNERFOO . 0) (TESTVARS . 2))

Don't know if this applies to Mike's situation,  just my 2 cents.

[mkweaver]

I have seen this happen when using the arguments in a function defined within another function

Code: [Select]

(defun testVars (pArg1 pArg2 / Test1 Test2 Test3)
    (defun InnerFoo ()
         (setq testThis (+ pArg1 pArg2))

    );defun innerfoo
    (setq Test1 (+ pArg1 pArg2)
  Test2 (+ pArg1 2)
  Test3 (+ pArg2 3)
    )
   (princ (strcat "\nTest1 = " (itoa Test1)))
   (princ (strcat "\nTest2 = " (itoa Test2)))
   (princ (strcat "\nTest3 = " (itoa Test3)))
   (prin1)
)



Code: [Select]

; === Top statistic:
; Global variables: (PARG1 PARG2 TESTTHIS)
; Function definition (with number of arguments): ((INNERFOO . 0) (TESTVARS . 2))


Don't know if this applies to Mike's situation,  just my 2 cents.

I do have a nested defun in my procedure, but it's vars are all declared as locals at the sub-procedure level.

I have improved the situation by using (function on my Lambdas, but this didn't solve the problems completely.

[SomeCallMeDave]

I may be wrong, but I don't think those variables and/or arguments will be exposed globally.  In my limited testing, they weren't exposed even when listed are globals by VLIDE.  I think it is a bug/feature of the syntax checker when it encounters nested function rather than a true global variable.

If you test it at the command line using !varname,  can you access the variables?

[mkweaver]

I may be wrong, but I don't think those variables and/or arguments will be exposed globally.  In my limited testing, they weren't exposed even when listed are globals by VLIDE.  I think it is a bug/feature of the syntax checker when it encounters nested function rather than a true global variable.

If you test it at the command line using !varname,  can you access the variables?

You are right about one thing - even though those vars are listed as globals, they are not visible outside the procedure.  So the syntax checker is failing:-(  However, the problem occurs even without the nested defun.  I have used nested defuns for a lot of years and have never seen this behavior.  I am going to have to watch these routines carefully to ensure the vars remain local or my routines will be tripping over each other left and right.

Thanks for the feedback.

Mike