Home |
Search |
Today's Posts |
|
#1
Posted to microsoft.public.excel.programming
|
|||
|
|||
User Public Type, circular dependancy error
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, whe 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, -- Neal Z |
#2
Posted to microsoft.public.excel.programming
|
|||
|
|||
User Public Type, circular dependancy error
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. Neal Zimm wrote: 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, whe 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, -- Neal Z -- Dave Peterson |
#3
Posted to microsoft.public.excel.programming
|
|||
|
|||
User Public Type, circular dependancy error
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 Z "Dave Peterson" wrote: 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. Neal Zimm wrote: 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, whe 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, -- Neal Z -- Dave Peterson . |
#4
Posted to microsoft.public.excel.programming
|
|||
|
|||
User Public Type, circular dependancy error
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 Z "Dave Peterson" wrote: 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. Neal Zimm wrote: 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, whe 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, -- Neal Z -- Dave Peterson . |
#5
Posted to microsoft.public.excel.programming
|
|||
|
|||
User Public Type, circular dependancy error
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 On Wed, 3 Mar 2010 09:04:01 -0800, Neal Zimm wrote: 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, whe 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, |
#6
Posted to microsoft.public.excel.programming
|
|||
|
|||
User Public Type, circular dependancy error
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. -- Neal Z "Chip Pearson" wrote: 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 On Wed, 3 Mar 2010 09:04:01 -0800, Neal Zimm wrote: 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, whe 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, . |
Reply |
Thread Tools | Search this Thread |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Forum | |||
Forms-Compile error: user-def type not defined | Excel Programming | |||
#13 type mismatch error on user form for Dave Peterson | Excel Discussion (Misc queries) | |||
#13 type mismatch error on user form | Excel Programming | |||
Help: Compile error: type mismatch: array or user defined type expected | Excel Programming | |||
User-defined data type; Error: Only User-defined types... | Excel Programming |