[AccessD] To a man with a hammer

[Daniel Waters]

What I'm doing has exactly the same effect in my Windows Forms (WF) application.

But as a form in WF is a class, I created a form class named frmParent, with what I needed for all forms.

When say, frmA is instantiated there is designer code which has all the specs for how the form should look when opened and what it's references are.  The first line in that designer code is 'Inherits frmParent'.  Then the frmA uses the properties, events, etc. from frmParent.  So I place 'Inherits frmParent' into the designer code for every form.  

And just like you're doing if I make a change to frmParent then all other forms will use those changes as well.

Pretty sure what you're doing will work exactly with the same effect as you've written it.  I was just trying to say that you have a Compadre in your thinking!  😊

All the Best,
Dan

-----Original Message-----
From: AccessD <accessd-bounces+df.waters=outlook.com at databaseadvisors.com> On Behalf Of John Colby
Sent: 16 February, 2023 09:05
To: Access Developers discussion and problem solving <accessd at databaseadvisors.com>
Subject: Re: [AccessD] To a man with a hammer

Daniel, what is (WindowsForms) frmParent.  Do you place all this stuff into a template form and then copy that as you start a new form?  Or do you have a class (clsForm) into which you place all this stuff?

The reason I ask is that while this is all stuff that validly belongs in a form's code behind form class, if it is in every form's code behind form class then if you want to change it for some reason, in order to propagate the change to every form you have to go into every single form and do so.

I can't tell from the comment above how you do this.

From a man who only has a hammer ;) ...

Drop all of that into a clsForm and then instantiate that class in every form's on_open, passing in the form to the class.  If anything has to be added, modified or deleted, do so in the class and everywhere the class is used the change appears.

That is the way I approach this.

On Thu, Feb 16, 2023 at 9:45 AM Daniel Waters <df.waters at outlook.com> wrote:

> Hi John,
>
> I agree on all counts!
>
> This is what I have in my (WindowsForms) frmParent:
>
>                 Me.ControlBox = True
>                 Me.MaximizeBox = False
>                 Me.MinimizeBox = False
>
>                 Me.ShowIcon = False
>
>                 Me.FormBorderStyle =
> Windows.Forms.FormBorderStyle.FixedSingle
>                 Me.SizeGripStyle = Windows.Forms.SizeGripStyle.Hide
>
>                 Me.ToolTipAllHover.OwnerDraw = True
>                 Me.ToolTipAllHover.Active = True
>
> Also the frmParent contains four ToolTip events which should be the 
> same for every form.
>
> And It's that simple.  Why? Because I don't want to constrain my 
> IMAGINATION from being able to make any form do whatever it needs to do.
> So, I do a little to easily maintain needed conformity, but not 
> anything that would be restrictive.
>
> I also use a common library file which contains all the functionality 
> that any customer might need - what a timesaver for me!
>
> All the best!
> Dan
>
> -----Original Message-----
> From: AccessD 
> <accessd-bounces+df.waters=outlook.com at databaseadvisors.com>
> On Behalf Of John Colby
> Sent: 16 February, 2023 07:22
> To: Access Developers discussion and problem solving < 
> accessd at databaseadvisors.com>; John Colby <jwcolby at gmail.com>
> Subject: [AccessD] To a man with a hammer
>
> In my opinion, the user interface is an absolutely critical part of 
> any app.  Too often the programmer treats the UI as an afterthought, 
> which ends up causing the entire application to be a disjointed mess.  
> I have designed dozens of applications for dozens of companies over 
> the 25 years I have worked in Access and over that time I figured out 
> UI things which should just always be the same, everywhere, in every form.
>
> Notice that in Windows, every single application has a set of three 
> controls in the upper right corner, a 'close', 'restore down', and a 
> 'minimize' button.  Always there.  Not sometimes there and sometimes 
> somewhere else, and sometimes not present.  In fact if we as 
> developers want that to not appear in our forms we have to jump 
> through hoops to make it not appear.
>
> So whenever I see a developer describing shoving UI kinds of things 
> into a form class, my mind cringes.  As soon as I place anything into 
> a form class that has any chance of being used twice I have started a 
> UI disjointed mess.  I have taken over other developer's projects, and 
> understanding all the crap in the typical form class is one of the major undertakings.
>
> As for a class being a hammer... in my view even saying such a thing 
> speaks volumes about the person saying it.  They either don't 
> understand classes or they have no imagination.  And yes, I get tired 
> of being told I have no imagination when in fact it is the person 
> saying such things which has no imagination.
>
> I have a class which wraps every single data aware UI object in 
> Access, think textbox, combo, radio button etc.  I have a pair of 
> classes which collect errors as they occur.  I have a class which logs 
> anything.  The error handler class uses the log class to log errors 
> collected.  I have an FTP class, not as useful as it once was.  A 
> class to do MD5 hashes.  A pair of classes to parse and deal with 
> OpenArgs for when a form opens.  A pair of classes which read Sysvars 
> out of my SysVar table and caches them into memory so the app doesn't 
> have to hit a table every time.  A timer class of course.  A zip 
> class, with a matching unzip class.  And many more classes as well.  
> All, BTW, placed out in a framework library which can be referenced from any app I desire.
>
> What about those many varied purposes describes using a hammer to you?
> Well maybe, if you have no imagination I suppose.
> --
> John W. Colby
> Colby Consulting
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> https://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> https://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>


--
John W. Colby
Colby Consulting
--
AccessD mailing list
AccessD at databaseadvisors.com
https://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com