[AccessD] A2K ideas on Order Entry

*<phew>* didn't realize what I started... but here goes... Yes my
"ade" is an unbound application it's the FE for a Sql Server Database.
 And While listboxes get bound, many other items are populated via ado
recordsets to unbound controls.  It has been the best approach because
it is an ADP.

I was really trying to think of a cleaner approach to this screen w/
Order Entry...

where The form has critical information for the parties at hand, and
then the lineitems are listed below, but if the popup form is open,
and the user hits enter while in the qty box and exits it, I'd like to
make it so that the popup box closes automatically if there is NO data
in that field.

I tried a simple docmd.close in the textbox's OnExit event but keep
comming up w/ an error...

and if this was also considered a messy approach, perhaps streamlining it?


On Tue, 7 Sep 2004 11:32:20 -0500, dwutka at marlow.com <dwutka at marlow.com> wrote:
> 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