Frivolous User Specific Form Colours Functionality (1 Viewer)

[LGDGlen]

Hi All

On a number of my forms there are header and footer sections which are set to a specific colour but I wanted to make it a little more user configurable by allowing a user to select a colour theme/scheme that will apply to all headers and footers.

I already do a couple of things as a form loads and they are done in a module so i thought i could add me.formfooter.backcolor and me.formheader.backcolor VBA to that.

But i realised that wouldn't work so i changed that to:

Forms(formName).FormHeader.BackColor
Forms(formName).FormFooter.BackColor

Where formName is passed to the module VBA public sub

But this kept throwing up an error: "cannot find the referenced form"

I then thought it might be because of the form event order that might mean that on load the form isn't accessible so i tested that out by using the Current event but still get the same issue.

Its frivolous and not necessary which is all the more infuriating that i'm not able to do it as i'm sure its just a matter of understanding event orders and stuff like that.

If i put the code directly into either the load or current events like this:

    Me.FormHeader.BackColor = 12040191
    Me.FormFooter.BackColor = 12040191

then the header and footer back colours change, its just if i move it to a generic sub in a module that it can't find the form using the forms name so i just would like to understand why in case in the future i need to do something less pointless and need to do this

hope that makes sense. here is the code that i have in the module:

Public Sub setHeaderAndFooterColours(formName As String)
    Forms(formName).FormHeader.BackColor = 12040191
    Forms(formName).FormFooter.BackColor = 12040191
End Sub

And on the form event i do this:

Private Sub Form_Current()
    Call setHeaderAndFooterColours(Me.Name)
End Sub

i've also tried

Private Sub Form_Load()
    Call setHeaderAndFooterColours(Me.Name)
End Sub

And both do the same thing so pretty sure its just a my understanding issue

Kind regards

Glen

 

[arnelgp]

there is a ThemeManager in this forum (i just don't know if the link is working).
if not, burp me and i'll post the db.

 

[sonic8]

so i thought i could add me.formfooter.backcolor and me.formheader.backcolor VBA to that.

I've never heard about a FormFooter or FormHeader property. I would refer to those using the Section property.

 

[LGDGlen]

@sonic8 thank you but its the finding of the form part that fails not the header/footer bits, i tried using the section property and it does the same thing

 

[LGDGlen]

@arnelgp i'd be interested in seeing how it does it but again this was more just a bit of fun to break the monotony and didn't want to go full on with it so i'd just be happy to understand why its failing

 

[arnelgp]

i think you should see and try it.
here it is (it was posted in Public for the public, therefore anyone can use it).

 

[LGDGlen]

looks interesting i'm going to add it to a backup of my project and see what fun i can have with it thanks @arnelgp

 

[isladogs]

Peter Cole also has an excellent Theme Maker utility. See

UtterAccess.com

www.utteraccess.com

 

[Pat Hartman]

Letting users make design changes to the FE is poor practice. How will you incorporate them when you distribute a replacement FE?

 

[LGDGlen]

@Pat Hartman it was literally just header and footer colours on forms that have them, and it was more just to see how to do it and leave a few easter eggs for certain users than anything particular or practical. colour would have been logged against username in database and if usable retrieved from there, header and footer would have been set based on if colour exists against user or not, standard colour if not set, colour specified against user if set.

as i say it was just a bit of friday frivolity that annoyed me that i couldn't do in a more generic manner hence the question. the implications are that i might need to do something more specific and more business oriented in the future that could be based around this and i would like to understand why i can't access the form using the form name in a parameter variable to a generic sub in a module

 

[Pat Hartman]

Nice that you have time for Friday frivolity

why i can't access the form using the form name in a parameter variable to a generic sub in a module

You need to pass the form object.

Call myproc(Me)

public Sub myproc(frm as Form)

here you refrence the form using frm.somecontrol

 

[LGDGlen]

@Pat Hartman thank you for the info, i did try that earlier and got the following error:

but i have just realised the mistake i have been doing, the call to the module routine did not include "Call" in front of it. When i add that it works, although it does act weird with lots of rendering glitches before it settles down, this might be because i'm doing this in the load event and not in current event.

Someone might be able to tell me why

logFormUsed(Me.Name) - this works (obviously with the parameter being a string in the module VBA code)
logFormUsed(Me) - this doesn't (throws up type mismatch error) (with the parameter being a Form in the module VBA code)
call logFormUsed(Me) - this works (with the parameter being a Form in the module VBA code)

thanks in advance

 

[Minty]

To use it without the "Call " remove the brackets;

logFormUsed Me

It changes the scope of the parameter, I read about it somewhere recently but can't find the link.

 

[The_Doc_Man]

It changes the scope of the parameter, I read about it somewhere recently but can't find the link.

Doesn't change the scope so much as it changes ByRef to ByVal. Which means that you do what you do to a COPY of the parameter. I believe our friend MajP wrote about this at some length, if you decided to search for it.

As to these options:

logFormUsed(Me.Name) - this works if the called routine expects a name and uses it via Forms!Form(the-name-argument) to identify the form. In this case, the presence or absence of the parentheses is immaterial because in either case, what gets presented to the called routine is a name. That is, you could have equally used logFormUsed Me.Name to pass in the name of the form. The ByRef/ByVal options don't matter that much for scalar (non-object) variables that are likely to be Read-Only anyway.

logFormUsed(Me) - this doesn't work because you changed the expected variable type of the actual parameter by grouping it (because parenthesis cause grouping to occur). The correct syntax, as noted by Minty, would be logFormUsed Me - without the parentheses. The expected syntax for the no-Call invocation is <entry-point-name> <space or tab> <argument-list>

call logFormUsed(Me) - this works because that explicit-call syntax expects - and thus "eats" - the first layer of parentheses, because in that case, "Me" becomes what the compiler calls an "argument-list" that in this case has a single member argument.