User Public Type, circular dependancy error

[Neal Zimm]

Hi,

In a module I have in declarations,
Public Type uSx
var names...
end type

In same module , general code, a function, uSx = uSxMakeF(arg, arg, ....)
All was working well.

I moved the uSx record definition to another module, "above" uRecA, where:
Public Type uRecA
other vars ...
uSx as uSx
end type

I now get circular dependancies compile error pointing at the above function.
uRecA is not involved in the function.

What is the best practice module batting order that will get rid of this
error ??
I had thought that as long as the "user" of public types was below, or in a
module after the Public Type, that I would not get this error.

Me experience had been that in the uRecA example, as long as other public
types that it used were "above" it, the "find it to use it" requirement
would be met.

Thanks,

 

[Dave Peterson]

First, I would never use:
Dim Long as Long

So I wouldn't use a variable name that matches the type.

Dim myuSx as uSx
myusx = usxmakef(...)
(not usx = usxmakef(...))

And

Public type uRecA
...
myOtheruSx as uSx
End Type

I have no idea whether this will get rid of the problem, but I know it would
lead to less confusion on my part.

 

[Chip Pearson]

You are omitting the relevant portions of the code. The minimalist
description you write leads to code like

Public Type uSx
L As Long
M As Long
End Type

Public Type uRecA
L As Long
M As Long
T As uSx
End Type

Sub AAA()
Dim S As uSx
Dim A As uRecA
S.L = 1
S.M = 2
A.L = 3
A.M = 4
A.T = S

Debug.Print S.L, S.M, A.L, A.M, A.T.L, A.T.M
Debug.Print uSxMakeF(S, 10)

End Sub

Function uSxMakeF(x As uSx, y As Long) As Long
uSxMakeF = x.L + y
End Function


This code works fine. Without seeing more code, it is difficult to
come up with an answer.

Cordially,
Chip Pearson
Microsoft Most Valuable Professional,
Excel, 1998 - 2010
Pearson Software Consulting, LLC
www.cpearson.com

 

[Neal Zimm]

Dave, I'll try it.

The reason I use that naming convention is that I've seen it many times on
this board.

It also seems to help me rationalize standard field names when the same
field name appears in more than one public type, using the VBA editor.

uRecA.fldA
uRecB.fldA are both found by u*.fldA with whole word.

it has saved me some time over looking for "As uSx" and "As uOther" and
then examing each .fldname is the proc.


Thanks.
Neal

 

[Neal Zimm]

Sorry, did not include this with prior post.

I moved the procs involved to different modules and the function ran just
fine, even with the uSx As uSx, but I'll stop using that naming convention.

 

[Neal Zimm]

Chip,
Thanks, the code omission was not on purpose. My focus was on the
position of the procs in the module, and not the actual variable names
themselves. I'll revisit that and see what happens.

The procs did run after I did some looking at the project after moved the
code to different modules. Turns out that I forgot I had renamed some
modules using pf4 after inserting them into the project and the alpha order
of the module in project expolorer was NOT the same as their physical
sequence in VBA. I used Bovey's documentor and proved this.

Thanks,
Neal Z.