Access OOP examples wanted (1 Viewer)

[NauticalGent]

Object-Oriented Programming is Bad

Interesting take on OOP. I have lived some of his views while trying to tame the monster I inherited. I found myself rocking back and forth on simple issues as far as where to put the code (should I make a separate Module, should I put it in the Objects Class, do I make a "Utilities" Module, etc) instead of simply "just doing it". His metaphor about individually wrapped candies was spot-on!

All that being said, the true nature of this video really doesn't apply to most of us on this forum. A huge percentage of our coding is done within forms and reports which forces us to comply with OOP to some extent.

To a non-programmer such as myself, Access's code-behind-the-forms paradigm was a God-send. All of a sudden I could do cool things without having to take a butt-ton of CS courses and invest in pocket protectors.

Funny thing is, my first introduction to databases was with Paradox/PAL, which at the time was a break from traditional programming (or so I was told) but to really do anything spectacular with it, you had to write whole procedures.

When Windows 95 became the norm and subsequently MS Office, I rebeled against the machine and went an RDBMS strike until I was forced back into it in 2008. By then Paradox and all other RDBMS apps were marginalized and Access stood alone at the top.

I held my nose and started to learn it and after awhile I decided it didn't really smell all that bad and when Access became the reason for my employment a year ago, it smells 'purt damn nice.

Anyway, now that I have made this all about me, thanks for the video. It is refreshing to see different POV's on things.

Edit: On reflection, unless I missed something, the speaker never really spoke to the actual performance of OOP in relation to the other methods. Only the readability and other aesthetics. Hardly a solid platform to sell your case on...

 

[DBQueen]

I would like to know more of OOP. I was used to procedural programming during my younger years :banghead:.

I have seen some of Uncle Gizmo's video and they're very good.

 

[MarkK]

a sample User class

As per a conversation with John (Nautical Gent) in a thread about global variables, here is a basic User class that you might implement or customize or whatever. Your data access doesn't have to be as complicated as that cDataRecord class I use in there, but that's just my stock data access class so I'll leave it in. Note that this is just the User and doesn't have a related table/class for logins and logouts, which would make a ton of sense to add, but maybe this gives some idea of how to get started.

To make this work, double click the fUser form. Your Windows username will not likely be present in the table, so a Wizard will pop up right away to help you add yourself.

After that, opening the fUser form will automatically recognize your Windows login, and load your record from the table into a new instance of the class. You can also spoof other users by making a selection in the combo.

Makes sense?
Mark

 

[NauticalGent]

MarkK, thanks for the example. I fiddled with it to suit my needs and although some might argue that I am using a bazooka to kill a mosquito, there are some distinct advantages that I think are available to me now.

I was using Public Type Variables to hold user info - I thought they were neat because they were always at the ready but I didn’t like having system resources been used on holding it in memory. Probably over reacting but I am a product of the DOS/64k generation.

Also, although I have not been able to duplicate the event, I have experienced where my application “forgot” the user info after the user had logged in.

What I like about your Class Module is how I can recall what I need on demand regardless of what hiccups may occur during a session, not to mention future expansion if I need to add user validation-based input and how to handle those situations.

Thanks again for posting...

 

[MarkK]

You bet John. Another thing I like about using classes is that the class becomes the central location for any and all business logic related to that type of object.

As a beginner I remember maybe I would write some functionality I needed into a form, but then later on perhaps I would need to duplicate that functionality in a report. So I could copy the code, or open a hidden instance of the form, but if you write a class and put all that class's related functionality in the class module, then it becomes a really useful organizing principle in how to write overall systems. You can instantiate that class in whatever context you need it--form or report or other class--and it exposes it's members via intellisense. Then when you come back to your code six months later, adding features--and not duplicating existing ones--is considerably simplified.

Cheers,

 

[jdraw]

There is a lot of info re OOP and Access and Interface in this thread by jLeach

 

[Leo_Coroneos]

OOP in 90 seconds

This is an outstanding link, a brilliant exposé of OOP and the principles behind it.

I don't know who posted the WithEvents link, but that one is even more awesome.

Geez, I feel like a kid in a candy store, only the candy is programming concepts, and my brain--which assimilates them--is equivalent to my greedy mouth licking and gnawing the candy.

 

[jdraw]

Just wanted to add a link to a class and related info from MarkK

 

[jdraw]

Here is a youtube video by PDTech describing his routine/class module to adjust and resize form controls.
His code is available as mentioned in the video.

I also want to highlight this link by Mile-O on a user authorisation/login class. I think this may have been the original question by spikepl that spawned this thread. Anyway, I am including the link since if provides the code and description.

 

[MajP]

Here is one I did recently that demonstrates a lot of concepts. Capturing multiple events from multiple objects, raising cutom event, and trapping custom events. I replaced an Active X spinner control with a class.

https://www.access-programmers.co.uk/forums/showpost.php?p=1597584&postcount=7

This has features that make it more flexible than a real spinner.

 

[Minty]

I'm at the start of learning a bit of C# online and totally coincidentally picked up on this article. https://medium.com/codeiq/object-oriented-programming-the-trillion-dollar-disaster-️-92a4b666c7c7

In the opinion of those far more knowledgeable than me is this actually pretty true ?
Personally I have always thought that whilst OOP looks like it could be nice, it seems to add complexity to simple tasks?

 

[MajP]

Personally I have always thought that whilst OOP looks like it could be nice, it seems to add complexity to simple tasks?

For me I would say the other way around. It makes a complex task simple.
I am not familiar with some of the very modern languages that are non OOP, so would have to learn about those, but there are things I have coded that I could not imagine how it could be done without OOP.

 

[The_Doc_Man]

Like all endeavors, OOP is a "pay me now or pay me later" type of activity.

When done well, it makes use of that object class almost trivial. When done poorly, you find it harder because (perhaps) the class is missing some important methods or properties that have to be done outside of the class context. This is true in any language that supports the concept of OOP. It is still only as good as the programmer.

The decision to go "object oriented" leads to a project for which all of the normal rules and guidelines apply - lay it out beforehand, do a thorough analysis of required functionality and the data needed to support same, test it to a fare-thee-well. That's the same advice we give to so many here. The fact of it being OOP doesn't change the fact that it is a programming project of some complexity for which there is a cost and there is a benefit.

So does OOP add complexity to simple tasks? It could. Does OOP make complex tasks simpler? It could.

The fact remains that any truly compiled language can do anything that any other compiled language can do. But that doesn't mean every language presents the same difficulty in doing so. C variants and Pascal variants are pretty good about structuring. BASIC and FORTRAN, less so. Let's NOT bring up COBOL for OOP. Visual Basic is the attempt to overcome BASIC's primitive structuring capabilities. It becomes possible with VB and its VBA bastard child to have a language that supports methods and properties, but even something so clunky as P/L-1 allowed language extensions to support OOP.

As always, the focus should remain on the goals and the process by which you reach them. Pay now, pay later. We've all seen it.

 

[NauticalGent]

I'm at the start of learning a bit of C# online and totally coincidentally picked up on this article. https://medium.com/codeiq/object-oriented-programming-the-trillion-dollar-disaster-️-92a4b666c7c7

In the opinion of those far more knowledgeable than me is this actually pretty true ?
Personally I have always thought that whilst OOP looks like it could be nice, it seems to add complexity to simple tasks?

Interesting that you of all people would post that Minty! Assuming that Class Modules ARE OOP, then the rest of my post is accurate, if not then it would not be the first time I ran my mouth needlessly...

It was YOU Minty that made me aware of what a Class Module can do:

https://www.access-programmers.co.uk/forums/showthread.php?t=294107

FMS has a very robust error handling Class that is a bear to retro-fit but once you get all the bugs ironed out, there is no going back.

MarKK’s User Module (discusses earlier in this thread) comes in handy as well.

All that being said, not being a true programmer, I cannot argue for or against OOP. But the ability to do what little it does (that I’m aware of) makes it worthwhile for me.

 

[jdraw]

Here is another link I stumbled upon when looking for a MouseOver Event. Yes, I know there is no intrinsic MouseOver event in Access, but found this and thought someone may find it useful.

 

[Pat Hartman]

The very worst Access app I ever had to modify was created by an "expert" developer who decided that he needed to apply OOP to Access. EVERYTHING was seven or more levels deep and at the end was rarely more than a couple of lines of code and many were just one line. It was a nightmare to try to follow the logic and eventually modify it. The first change was small and I managed to do it but I told the client - never again. If you want something done with that app, I'm going to have to rewrite it. I probably spent 10 hours doing something that even in an application that I had never laid eyes on before should have been less than an hour.

I'm glad to see that others have come around to my opinion.

Coupling and Cohesion were big words back in the 80's and they have stood the test of time. Applications/programs/procedures should be highly cohesive and loosely coupled. What that means is your payroll application should not be scheduling the shop floor just because they share a calendar table. And nothing should require large numbers of arguments to operate.

I once came across an error procedure that was hundreds of lines of code. Why? because the person who wrote it created error messages and assigned them numbers and then in the "common" procedure used a case statement to pick each error by number and do something different and display a unique message. What was saved by this? Nothing. It just abstracted the problem one level and made it harder to understand. Creating a table of error messages makes some sense because it makes things easier to find and messages easier to change if necessary but if you're going to do something custom for each error, do it where the error occurred, not in a "common" procedure.

Routines that are shared should do the same thing regardless of what initiates them. If they do something different when called from a than they do when called from b, then there is nothing common about the code and it would be easier to have two separate procedures. The called code should NEVER have to know what procedure called it to determine what to do.

 

[The_Doc_Man]

Pat brings up an excellent point that shows a major weakness of OOP. If you don't implement your object class very well, debugging becomes a multi-layered nightmare. A 7-layer Taco Salad can be a treat. A 7-layer object-oriented debug session can become a context nightmare. In terms of program logic flow or program data flow, diagramming such a beast can be horrific.

I would never go so far as to say that OOP is a bad idea. But there are problems where OOP is serious overkill vis-a-vis desired result vs. required effort. Therefore, when Minty says:

Personally I have always thought that whilst OOP looks like it could be nice, it seems to add complexity to simple tasks?

I have to agree with him. There is a level of effort that is appropriate to certain tasks for which OOP is too much work for too little return. And equally, there are certain projects where OOP is almost mandatory if you want to stay sane (and stay consistent) in what you do.

 

[CJ_London]

I use OOP for some things, but not all. Primarily for creating new events

Took a look at JDraws mouseover event link as I have written my own class to handle it. The code in the link is simpler than mine, but suffers from the same problem of the basic mousemove event of the mouse moving too quickly so the move event is not detected in surrounding section/controls - and may even no longer be over the form/access.

Mine uses a class timer event and behaves much like the button hover event or the event which displays the controltiptext

• On first detecting a mouse move event, code is run (e.g. to change the back color) and the class timer interval set - perhaps 10th of a second
• subsequent mouse move events do not rerun the code but does reset the interval
• when the timer event is triggered, it compares the mouse position with the control location - if still over the control (user might have stopped moving the mouse), it resets the interval otherwise it carries out the the required 'not over' event such as change the back color back again.

 

[jdraw]

CJ, perhaps you could post your class with a sample.


Here are a couple of youtube videos by Paul Kelly re Class Modules. He uses Excel (that's the basis of his business) but the concepts and examples apply to Access.

-Class Modules Explained in Simple English
-Class Modules with Collections

He has a lot of data structure materials at his website
-here's a class module tutorial

 

[MajP]

Some people have shown interest in custom classes lately, and was asked for some more examples. I use custom classes extensively, but the most important use in Access is the ability to extend control functionality and basically simulate building a user control. Once you build it once you can encapsulate a tremendous amount of functionality and reuse it without having to rewrite code. Normally it requires one or two lines to initialize the class. Here are a few examples

1) Find/Filter as you Type (FAYT). There are several classes here that turn a combobox, form, or listbox into a find as you type. In other words as you type it filters the list. There are several properties to configure how it filters

2) Listbox sorter. This captures the events of several command buttons and the listbox to allow the user to move records up and down in the list. It has lots of features to return the sorted list or row / column values.

3) From To List. Allows you to take any two listboxes and a group of command buttons and move items from one list to the other list.

4)MultiSelect Listbox control. This takes a multiselect listbox and returns a filter string based on the bound column

I have replaced the Multiselect Listbox control. The previous file was not the correct file and was not a custom class.