[AccessD] A2K ideas on Order Entry

DWUTKA at marlow.com DWUTKA at marlow.com
Tue Sep 7 14:04:13 CDT 2004


Oh, good point.  I've only had one cup of coffee this morning, so I'm a
little out of it still! <grin>

Yes, you could use a bound form, and still trigger from a global class.  It
is still a little more 'backwords' work though, because then the form has to
capture what is done on it, and send it to the global class, versus letting
the global class do all of the work, and send it out as an event.  Just two
different approaches.

Ironically, the initial concept of the Inventory system I spoke of was going
to be VB 6.0, until the very last minute, when the contractor I work for
decided he wanted to be able to make changes of his own, so he insisted on
Access 2000.  Ugh.  Would have prefered VB 6.0, so instead, he got a VERY
heavily coded Access 2000 app. <grin>

Drew

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com]On Behalf Of John W. Colby
Sent: Tuesday, September 07, 2004 12:58 PM
To: 'Access Developers discussion and problem solving'
Subject: RE: [AccessD] A2K ideas on Order Entry


Drew,

I understand what you are saying but there is no reason a bound form cannot
use (reference) those same business classes.  That's all I'm saying.  It has
absolutely nothing to do with bound / unbound.  I (mostly) use bound forms.
But I routinely reference business classes from those forms.  The form's
class references the class Withevents and can now sink events from that
class if it needs to.

If a new form needs to receive messages from that class then it simply gets
a pointer to that class instance.  By dimming the class global in a module
(and initializing it there) ANY form (or any class, since a form is just a
class after all) can grab a pointer to the class and sink any events
broadcast by that class.  

You didn't say whether these unbound forms are getting a pointer to an
instance of a single (global) class or dimming an instance of the class in
each form.  Either way, a bound form can do exactly the same things.  If a
business class instance is created for each form then a message channel such
as I described previously allows intercommunication.  The business class
instance sends a message on the (global) message channel.  If a global
business class instance is used by all forms, then each form grabs a pointer
to the global class instance directly and calls methods of the class to
inform the class (other users of the class) that it has manipulated data,
and sinks it's events to determine that other forms have manipulated data.
Either way, bound or unbound doesn't matter.  

I agree, this is not about bound vs unbound, but rather whether the same
concepts can be applied or used and they most certainly can.  I simply don't
want our members saying "oh, I'm using bound so I can't use that idea".  Of
course they can, I do every day.

John W. Colby
www.ColbyConsulting.com 

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of DWUTKA at marlow.com
Sent: Tuesday, September 07, 2004 12:32 PM
To: accessd at databaseadvisors.com
Subject: RE: [AccessD] A2K ideas on Order Entry


I was referring to unbound forms because in the business logic structures I
have built, the business logic is built into stand along classes.  These
classes can then be used by any form.  So the classes let the forms
interact.  Yes, you can put events into bound forms, but you don't have the
same 'interaction' then.

For instance, in Francisco's original message, he could get around his
particular issue by creating an event for his main form, which he can sink
into his popup form, so when he triggers that event, the popup form receives
it, and acts appropriately.

In my case, I built the entire structure that way, so one interaction is
seen by all that need it.

Here's an example.  I built in Inventory Class.  This class can be used to
add inventory items, create inventory transactions, modify inventory items,
etc. etc.  Anything and everything to do with the inventory system required
by the business logic.  So now I build a few forms.  One to add/modify
inventory items (not actual transactions, but item definitions), on for
inventory transactions.  Now I also have a Site class (where inventory
goes/comes from, during transactions).  Same principle, it handles all of
the interactions with Sites.  The inventory transaction form uses both the
Inventory class and the Site class.  There is also a Site Add/Edit form. All
three forms work independantly, however, due to the events within the
classes, when something is done that 'could' affect another class, then
events are raised, and any open form that uses that class is notified.

I know this could still be done strictly with bound forms, but I think the
unbound approach is cleaner.  In the example above, I would need to
reference two forms, to capture any/all changes to the inventory (and if I'm
making a third form, I would have to go back and modify the first two forms
to handle the third), where as the central class method handles it all by
itself.  No going back to modify other forms, new forms can be built
whenever needed, and all of the existing forms need not be aware of them,
since they all work off of the same Inventory object.

Okay, nuff said, cause we don't need another bound/unbound discussion.

Drew

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com]On Behalf Of John W. Colby
Sent: Tuesday, September 07, 2004 10:18 AM
To: 'Access Developers discussion and problem solving'
Subject: RE: [AccessD] A2K ideas on Order Entry


Drew,

I most appreciate your observations re classes and events, but it is
unhelpful to cast them in the light of unbound forms.  Any class can
generate a custom event (even a form's class), they can do so without forms
even being involved, and they can do so to manage a bound form as easily as
an unbound form.

But yes, your observations re transmitting messages to other classes (and
forms) is right on target.  Way cool.

I use a set of classes to handle logging process messages to disk.  Have you
ever looked at SQL Server's log, or windows startup log?  Very handy to
troubleshoot what's going on when something fails.  I have a set of classes
that listens for an event (on a message channel in my case).  If they
receive that message (sink an event and the message is for it), the class
logs the message content into a disk file.

I use exactly the same process to log process status to tables when my
program needs to monitor process status.  A set of classes monitors a
message channel (sinks an event for a message class instance) and if the
message is for that class, writes the message content to a table.

Using "loggers" in this fashion allows my programs to log processes without
each piece having to know how to log to a disk file or log to a table.  It
simply calls a message class instance method and passes a to:, subject:, and
message: and the logger handles the rest.  I can have multiple logger
instances, one each process that needs logging, each instance knows it's
disk file name or table name and logs to the right place.

In fact I also use the message class for inter-form and inter-process
communications inside an application.  Once you have a message class built,
it is trivial to pass messages to any other class (only classes can sink
events).  My framework automatically starts one general purpose message
class so that is a known entity sure to exist.  Any process can send a
message on that message instance.  If a process needs it's own message
channel for some reason, it can ask the framework to open another instance
(stored in a collection by message channel name) and pass back a pointer to
that channel instance.  Now any set of classes involved in that process go
get a pointer to that message channel instance and use that as a private
message channel.

Custom events allow processes to be "black box", do their thing, and
broadcast an event when some thing happens.  That is extremely useful in
interface design since it isolates classes.  The matching part (or parts)
don't have to be running to test, different parts can sink the events in
different situations etc.

This stuff is way cool.

John W. Colby
www.ColbyConsulting.com 

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of DWUTKA at marlow.com
Sent: Tuesday, September 07, 2004 10:12 AM
To: accessd at databaseadvisors.com
Subject: RE: [AccessD] A2K ideas on Order Entry


The beauty of unbound forms, with custom classes handling your processes, is
the ability to create your own events.  I have built several projects where
the forms display data based upon Global Class Objects, which interact
through events.  For example, I have an Inventory object, that has an
'inventory changed' event.  Whenever something happens to the inventory
(which is done through this class), it raises that event, and all open forms
that have are using this class receive that event, and thus update
themselves with the new information.

Yes, it takes a little longer to set something like that up, but it is
extraordinarily handy as you build more complex and 'smarter' applications.

Drew

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Francisco Tapia
Sent: Saturday, September 04, 2004 1:53 AM
To: Access Developers discussion and problem solving
Subject: [AccessD] A2K ideas on Order Entry


Brainstorming here:

I have a parent form which houses important order entry information such as
Billto/Shipto, PO#, SO#, and Notes... along with that I have a listbox (but
have been working on a readonly subform datasheet view).

Users currently go into a popup window box to add new lineitems to this
order.  However... I'd like to control where the popup box hovers over...
meaning allowing for the subform to be viewable while the popup form is on
the screen.  This allows ME to refresh the subform to display the newly
entered items.

now currently while in the popup mode, I've made it so that as soon as one
line entry is complete, the form display clears out to allow another entry,
and thus all the data entry guy has to do is key in the new qty etc. for his
order.  but once he is done, I use a keypreview to capture the ESC key to
allow them to get out.  I thought about what if they could just hit ENTER
and when the QTY field is null it should kick him out, but I get a bizzar
error on the .OnExit event of the Qty Field.  thus I can't exit the form
while it's processing or something like that....

any ideas?.. (yeah I realize that its' 12:00am PST but that's when the mind
is wandering :D)

thanks,



-- 
-Francisco
-- 
_______________________________________________
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com
-- 
_______________________________________________
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com



-- 
_______________________________________________
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com
-- 
_______________________________________________
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com



-- 
_______________________________________________
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com



More information about the AccessD mailing list