 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
MS Access Forum / Multiuser / Networking / October 2004MsAccess Form as an Object-with-Methods (class?) that can have descendants?
Hi All, To what extent is MsAccess truly object oriented? I have a db with several forms that use an ObjectTree on the left side of the space and to the right I have the associated data (in several subforms that can be changed via the SourceObject property, depending on the selection in the ObjectTree). Now I have written code that keep the data and ObjectTree in sync & by clicking on the ObjectTree the associated data is displayed for editing. Also drag & drop in the ObjectTree has an effect on the associated data. Now I find myself duplicating code for each form, with slight differences because they handle different data tables. (1) That should be avoidable when I could design one 'parent' form with a generic set of methods that I then can use as an object that I can declare 'decendants' from: I then only need to implement some net-changes to make it work for every such form. Is that possible in MsAccess? (version 2002). (2) Next to that, though I have created nice looking forms, but in a multi-user environment with a shared back-end, I realise that I have created redundancy: my ObjectTree (in each front-end) duplicates some key data from the data in the back-end to reflect the structure of the data. Now, when the back-end data changes, that does not lead to an update of the ObjectTree in each front-end (of course). If I want to make it truly multi-user, I would look for a mechanism to put every (relevant) data change through some 'queue' table in the back-end that would have to be processed by every active front-end. The use of inherited methods would also be of great help here to keep the program managable! Am I expecting too much of MsAccess here, or is there a good example somewehere of Forms_as_ojects_that_can_have_descendants? Thanks, Vincent Forms are, indeed, classes, but Access form classes do not support inheritance. (You can, for example, instantiate multiple instances of the same form {though some find it a little hard to keep track of which is which}.) However, if you "back off" from thinking that the object-oriented way is the only way, there's a good chance that you could put the pertinent code in a standard module, made sufficiently generic that you could call the same code from each form. Then copy the form, with the "personalization code", change the RecordSource to refer to the proper data and the personalization code (references to the data) and you'll have (something, at least close to) what you want. It's possible, if you feel compelled to do it with a class, that you could use a separate class module, rather than a standard module. I am not certain what, exactly, you mean by "object tree duplicates some key data in the front-end"... indeed, I am not fully certain I understand what you mean by "object tree", if not the Treeview (a control that comes with the Office Developer edition, and may come with the Visual Studio Tools for Office 2003 system) Control. It is very easy to implement solutions to common, "normal" business database problems with Access -- if you learn and do it "the Access way". The fact that the Access way is not fully object-oriented has not kept us from solving more "normal" business database problems in the last eleven years than, I venture, have been solved with any other database product or combination of database products. But, I observe that the quickest route for many to frustration and disliking Access has been to expect it to be just another version of some other product or technique -- no matter how they try to force-fit, it just isn't that other thing, and they find it very frustrating. Larry Linson Microsoft Access MVP > Hi All, > [quoted text clipped - 32 lines] > Thanks, > Vincent Hi Larry, Thank you very much for your elaborate answer! Your answer is indeed what I was looking for; I was not sure if (A) I was overlooking some great features of Access and therefore doing it the clumsy way, or (B) that I was actually taking full benefit of Access and doing it the right way. Now I know it's not (A) and how to improve my (B) approach. And, yes you're right: I meant the TreeView object. This also goes to the multi-user part of my question: upon changing a record in the back-end database, all users will work with the changed data (after refresh when already open). Since I copied some of that data into the local Front-End TreeView object, the result will be a mis-match between data and TreeView object. To avoid this, I do have code that will update the TreeView object when data is changed in the Front-End, but that only works for the user working with that Front-End. All other users with their own Front-Ends will end up with the indicated mismatch. It is not crucial, with good error trapping and a 'redraw TreeView' function I can manage. It's more out of curiosity whether anyone would have a nice solution... Thanks again! Vincent > Forms are, indeed, classes, but Access form classes do not support > inheritance. (You can, for example, instantiate multiple instances of the [quoted text clipped - 73 lines] > > Thanks, > > Vincent If you code so that each Form is only working on a single record (it is surprising how often you need to retrieve only one record, if it exists, or none, if it doesn't), and your application requirements are "normal" so that you don't ever, or don't often, have two users updating the same record at the same time, then you don't have a problem. But that wouldn't solve the problem for the TreeView. I haven't ever used the TreeView control in an Access application. Though back in earlier days, I did use a similar third-party control from FMS, Inc. in a demo, there was no worry about another user updating. Am I correct that the TreeView canNOT be bound to an Access table, but that you have to populate it from code? If so, it is a control I would avoid like the plague because you lose a big, big advantage of Access -- unlike some other languages/tools, Access works very well with bound Forms and bound Controls and using them saves you lots and lots of time and effort in implementing. Perhaps the easiest solution is to rethink the design and use something other than the treeview... e.g., ComboBox selection of whatever is the subject of your Form. Both the Form and the Combo Box are subject to the timeout for refreshing with data from the back-end tables. I am sure you are aware that an Access-Jet application does all its processing on the user's machine because of the file-server nature of Jet databases. That is, the back-end is used exactly as if it were a file on the local hard drive, only anything read from the backend by Jet has to come across the network (unless, of course, the split backend is on the local machine). Thus, minimizing network traffic is a very important factor in performance of Access multiuser applications. The best links and information on this subject, and on avoiding corruption in the multiuser environment can be found at MVP Tony Toews' site, http://www.granite.ab.ca/accsmstr.htm. (BTW, the name of the sponsored newsgroup for code-and-forms is microsoft.public.access.formscoding, not "formsprogramming".) Larry Linson Microsoft Access MVP > Hi Larry, > [quoted text clipped - 117 lines] > > > Thanks, > > > Vincent Hi Larry, Thanks again!. I am indeed not afraid of record locking issues. It's just the data in the TreeView dat is rendered 'out-of-sync' with the multi-user data out of the database. Yes, you're right that the TreeView (part of Microsoft Windows Common Controls) can not be bound to an Access table, it's populated through code. And it's true that it's a lot of work to make it work well. Yet I have chosen to use it since I think it brings a lot of added value as well. This lies in the fact that a TreeView provides great overview of the structure thay you work with & navigating method, and gives the form an appealing look including nice custom icons. Just like the Windows Explorer does: with folders on the left and documents on the right. I am indeed aware of the way that the Front-End and Jet are running on every user's machine and that the (back-end) database on the file server is basically nothing more than a shared file. I have studied Tony Toews' site a while back and found it very helpful. You made an interesting remark: "Both the Form and the Combo Box are subject to the timeout for refreshing with data from the back-end tables.". Am I right to understand that MsAccess will automatically dispay changes in an opened recordset (at a particular time interval / frequency) to reflect any changes made to the database file, even when that change was caused by some other user? The MsAccess or Jet process on the user's machine would never know since they do not communicate process-to-process with instances on other machines. Does MsAccess trigger a refresh on opened recordsets at a certain frequency? If there is something like that, and it would cause an Event that can be picked up, and even better, when it is also possible to find out what records had to be updated to show the new content....(ALL the changes?) then there is a neat way to use that information to synchronise the TreeView. Again, this is not really important 'an issue', since the application works fine, it's out of curiosity and interest in the technology behind it! I'll switch to 'microsoft.public.access.formscoding' ;) Vincent > If you code so that each Form is only working on a single record (it is > surprising how often you need to retrieve only one record, if it exists, or [quoted text clipped - 178 lines] > > > > Thanks, > > > > Vincent There's no event when someone else updates shared tables. And, frankly, I don't know exactly how the refresh interval works. <SIGH> Larry Linson Microsoft Access MVP > Hi Larry, > [quoted text clipped - 244 lines] > > > > > Thanks, > > > > > Vincent |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.