Re: Circular dependencies between modules
From: Jim Shaw (jeshaw2_at_comcast.net.work)
Date: 11/23/04
- Next message: Roger Carlson: "Re: ...= Nz(DMax("..."
- Previous message: stefan hoffmann: "Re: Coding the Winsock control...."
- In reply to: Michel Walsh: "Re: Circular dependencies between modules"
- Next in thread: Michel Walsh: "Re: Circular dependencies between modules"
- Reply: Michel Walsh: "Re: Circular dependencies between modules"
- Messages sorted by: [ date ] [ thread ]
Date: Tue, 23 Nov 2004 09:10:13 -0500
Michel! Thanks for responding, but I'm still in trouble in several places.
-------First, I can't make your call logic
work---------------------------------------------
In Access 2002, I set up the following two trivial forms to test your call
logic and I can't make it work. I have:
"frmB" defined with a text box "txtB" and
Public Sub SetData(txtA As String)
txtB = txtA
End Sub
frmA defined with a text box " txtA"and
Private Sub txtA_AfterUpdate()
Call Form!frmB!SetData(txtA)
End Sub
With both forms loaded, I type data into txtA and exit the field.
I get a syntax error on the call statement in frmA!
I've tried other syntax approaches, but they all result in compile errors.
Can you help me here?
-------Second, I'm confused----------------------------------------
You wrote: "Events are only allowed for class, not for modules."
In a form, when I write event property VBA code, the form's property "HAS
MODULE" is set, by VBA, to "yes".
>From that I assume that the code I've written is in a "module" and the form
itself is an "object" of a forms class.
I have user defined events working in these modules!!?? And they are not
allowed for modules? My problem is: They work for monologs only, not for
dialogs. (i.e., one way communication only) I get circular definition
errors on dialog type coding.
Can you clarify this for me?
If I write my own "class" (as I have in this application), I fail to see how
to code an initiator event (or object load event) sub routine, to prepare it
to sink events... I can't find those events in the class definition
features of the VBA language.
Can you tell me how to do this?
I guess my understanding and experience is the reverse or yours..."events
are for modules and not for class"...?
-------Third, You asked, so I'll share with you, my reason for using event
code--------------------------
I am basically an object oriented programmer who normally works in true
object oriented languages and I'm trying to use that metaphor to implement
my inter-module communications here in VBA. (My client is making me do that)
I'm basically self taught in VBA.
I'm willing to pay a little in performance to achieve more important
benefits.
Calls, such as you recommend, are bound to specific forms at coding/compile
time. An explicitly coded call is needed for each "listening" form.
With events, I can add "listeners" at will during application development
/execution time without having to add additional calls.
With calls, I must add logic to assure the listening form is loaded before
each call is executed, or the logic will crash. Not elegant.!
With events, I don't have to worry about "who", or "whether" anyone, is
listening to broadcast messages, thus achieving better decoupling between
forms and improving encapsulation.
In a nutshell, event based messaging leads to more robust applications that
are more easily understood and maintained over the long haul. Well, its
just my opinion and I submit to your better experience with VBA. I don't
want to start any programming style wars here (Smile)
However, I'm beginning to understand that what I'm trying to do with VBA may
be too advanced for the features of the language. So I'm trying to get your
approach to work. At least that way I can finish this application and get
on to other stuff.
Your help would be appreciated.
Thanks,
Jim
"Michel Walsh" <vanderghast@VirusAreFunnierThanSpam> wrote in message
news:%23IKHVIJ0EHA.3124@TK2MSFTNGP10.phx.gbl...
> Hi,
>
>
> Events are only allowed for class, not for modules.
>
>
> Why you don't use standard CALL. Instead of
>
> RaiseEvent AddedClient
>
>
> use
>
> CALL FORM!FormClient!AddedClient( )
>
> or similar?
>
>
> There is less overhead with a standard subroutine call than there is with
an
> event. And since it seems you code BOTH the class that "raise the event"
and
> the class that respond to it, YOU ARE IN CHARGE along the whole process,
and
> the event model is thus an un-necessary complexities.
>
>
> Sure, that does not answer to why you got a circular reference in your
> "modules"... That can happen if you refer, from dbA.mdb, in the libraries,
> to dbB.mdb and dbB.mdb refers... to dbA.mdb. That is a COM circular
> reference of library.
>
>
>
> Hoping it may help,
> Vanderghast, Access MVP
>
>
> "Jim Shaw" <jeshaw2@comcast.net.work> wrote in message
> news:%237M5ODnzEHA.1300@TK2MSFTNGP14.phx.gbl...
> > Blank At "compile time" I'm getting a "Circular dependencies between
> > modules" error message.
> > What is the problem??
> > Is there a work-a-round?
> >
> > It came up while coding my own events with the "With Events" syntax to
> > realize Bi-directional inter-module communicattion / synchronization via
> > event messaging between four forms.
> >
> > Can it be that Bi-directional event messaging between sibling objects is
> > not
> > allowed in VBA??!!
> >
> > I got into this because of a user initiated change request that form
> > objects
> > which were initially defined as independent of each other, are now
> > interdependent in a way that needs some type of control over the order
of
> > event processing if I'm to save tons of existing code. Being unable to
do
> > that directly (aparently VBA makes up its own mind on the processing
order
> > of user raised events), I'm trying to get the form objects to explicitly
> > talk to each other and stay sync'd up that way.
> >
> > Hopefully this background info will help...
> > CONTEXT: Access/2002, MS/Windows 2000 Server
> >
> > The four forms are loaded in the following order
> > "frmEmpMaint" This is the "Main" form
> > "subEmpCompDataHist" A sub form on the Main form
> > "frmAddNewEmp" Optionally loaded by Main form logic
> > "frmEmp850Criteria" Optionally loaded by Main form logic
> >
> > The last two forms are not normally open at the same time and there is
no
> > attempt to communicate between them. I'm trying to keep
frmEmp850Criteria
> > synchronized with the first two forms. Either of these three can
initiate
> > a
> > a need for the other two to react. I don't think "frmAddNewEmp" is
part
> > of
> > the problem because I had that code working.
> >
> > These Events are used to synchronize (i.e.; move to related records in
> > their
> > underlying table) forms:
> >
> > AddedEmp(EmpID as String) signals that a new employee has been added
> >
> > NewEmp(EmpID as String, Name as String) signals that a form has
moved
> > to a new employee in its underlying file
> >
> > NewEmp(RecComp as form) signals that a form has moved to a new
> > employee
> > in its underlying file
> >
> > CurrentRec(RecComp as form) signals that a subform has moved to a
new
> > history record in its underlying file
> >
> > SyncTo(SyncDate as date) signals a request to move to a record
having
> > an EffectiveDate of SyncDate.
> >
> > SyncOK(SyncDate as date) signals a successful move to the requested
> > record
> >
> > SyncFailed(SyncDate as date) signals that no record exists having
an
> > EffectiveDate of SyncDate.
> >
> > RecComp is a form object which raised the event thus providing
> > addressability to its underlying record.
> >
> > The forms have the following specifications and code snipits that I feel
> > are
> > relevant to the problem:
> >
> > ----------------------------------------------------------------------
> > "frmEmpMaint"
> > -------------
> > Underlying table: tblEmployee (PK: EmpID)
> > Events Raised:
> > NewEmp(EmpID as String, Name as String)
> > Form850Loaded()
> > Events Sunk:
> > frmAddEmp_AddedEmp(EmpID)
> >
> > Private Sub CmdNew_Click()
> > DoCmd.OpenForm 'frmAdNewEmp",,,....
> > Set frmAddEmp = Forms!frmAddNewEmp
> > End Sub
> >
> > "frmAddNewEmp"
> > --------------
> > Underlying table: tblEmployee (PK: EmpID)
> > Events Raised:
> > AddedEmp(EmpID)
> > Events Sunk:
> > None
> >
> > "subEmpCompDataHist"
> > --------------------
> > Underlying table: tblEmpCompDataHist (PK: EmpID & EffectiveDate)
> > Events Raised:
> > NewEmp(RecComp as form)
> > CurrentRec(RecComp as form)
> > SyncFailed(SyncDate as date)
> > SyncOK(SyncDate as date)
> > Events Sunk:
> > frmEmp_NewEmp(EmpID as String, Name as String)
> > frm850_SyncTo(SyncDate as date)
> > frmEmp_Form850Loaded()
> >
> > Private Sub Form_Load()
> > Set frmEmp = Forms!frmEmpMaint
> > End Sub
> >
> > Private Sub FrmEmp_Form850Loaded()
> > Set frm850 = Forms!frmEmp850Criteria
> > End Sub
> >
> > "frmEmp850Criteria"
> > -------------------
> > Underlying table: Unbound form. Uses qryDefs to access needed tables
&
> > data
> > Events Raised:
> > SyncTo(SyncDate as date)
> > Events Sunk:
> > frmComp_NewEmp(RecComp as form)
> > frmEmp_NewEmp(EmpID as String, Name as String)
> > frmComp_SyncFailed(SyncDate as date)
> > frmComp_SyncOK(SyncDate as date)
> > frmComp_CurrentRec(RecComp as form)
> >
> > Private Sub Form_Load()
> > Set frmEmp = Forms!frmEmpMaint
> > Set frmComp = Forms!subEmpCompDataHist
> > End Sub
> >
> > ----------------------------------------------------------------
> >
> > Believe it or not, this all makes sense to me. 8-)
> >
> > Thanks
> > Jim
> >
> >
>
>
- Next message: Roger Carlson: "Re: ...= Nz(DMax("..."
- Previous message: stefan hoffmann: "Re: Coding the Winsock control...."
- In reply to: Michel Walsh: "Re: Circular dependencies between modules"
- Next in thread: Michel Walsh: "Re: Circular dependencies between modules"
- Reply: Michel Walsh: "Re: Circular dependencies between modules"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
