DataBase - ACCESS TITLE BAR

How can I change the Access title bar with VBA?

Can anybody post an example?

  Paolo replied to Jess

Hi Jess,
This work until aceess 2003, I do not know for newer version:
Add this function in the first form that you open

Function AddAppProperty(strName As String, varType As Variant, varValue As
Variant) As Integer
Dim dbs As Object, prp As Variant
Const conPropNotFoundError = 3270

Set dbs = CurrentDb
On Error GoTo AddProp_Err
dbs.Properties(strName) = varValue
AddAppProperty = True

AddProp_Bye:
Exit Function

AddProp_Err:
If err = conPropNotFoundError Then
Set prp = dbs.CreateProperty(strName, varType, varValue)
dbs.Properties.Append prp
Resume
Else
AddAppProperty = False
Resume AddProp_Bye
End If
End Function

Then on the open event of the form put this code

Const DB_Text As Long = 10

intX = AddAppProperty("AppTitle", DB_Text, "Your title") ' this set the
title
intX = AddAppProperty("AppIcon", DB_Text, "your icon with full path") '
this set the icon if you like
Application.RefreshTitleBar

HTH Paolo

Outlook (1) I should note that I am using the data macro to call a VBA function (by setting a local macro variable to the result of the function call). So this is not for the web, I did not see a problem with calling a VBA function (and various places I have seen online mentioned workarounds for calling VBA from a data macro). But, again, while it works when I insert a record in note? In it I added that I was using the AfterInsert macro to run some VBA code (by setting a local variable to the result of a function call). Maybe that maybe that is the problem Yes, in this case, you need a copy of the VBA in the front end. (for testing you can place it in both - since if you happen to open the back end table directly, then the VBA code is ALSO required since the front end might not even be open and the talk to that may be sitting on your computer. So when the trigger fires, that VBA code will be required. So, the VBA needs to exist in the front end if that all you opened. However, if you

reusable for more than one client. So we now develop to a office standard (and VBA). Our next and software for the cloud will be built to the sharepoint standard (at shape to be compatible for upload? But not with native Access forms. Not with standard VBA. This means it may be *similar* to Access (and thus very easy for us to web, and one for local. In fact you can even execute an open form from VBA and openform works fine if you feed it a web form name. as mentioned, you can have a mix of VBA forms, and web only forms in the same application. When you publish the application, those help you trace the interconnections between all the macros, the same way you can with VBA. This is my biggest concern about all of this, that by going to macros, you client and the web. However for some things like payroll processing etc then you need VBA. Obviously only the controller / accountant person in your organization will need the advance VBA part of the application. For employees to enter their time sheets and hours, check their not for a very, very long time (despite the false dawn of Office 97 with VBA as platform for developing complex meta-apps for small businesses). I do not quite understand

VBA vs Macros DataBase Let me preface this by saying it is a sincere question. I Using Access 2010 I note that help tells us to use macros in preference to VBA for web apps and for greater security. Also a VBA to macro converter is provided but not the other way around. Why so down on VBA? Once upon a time it was considered that for any serious development VBA was preferred to macros because it had a) error trapping (where untrapped errors would crash runtime installation of Access) and b) greater power and flexibility. Are these two advantages of VBA over macros still true with 2010? Other than for web apps (which I am not doing) should I change to macros or stick with VBA? When I took up Access I learned VBA and only did macros when it was the only way for certain operations. Other than

big of post do you want? Perhaps the big news is the new version of VBA, or what we call VBA 7. This new version of VBA now has a true pointer data type called longPtr. We also get a 64 bit the term JET, but I really talking about ACE). Note that this new version of VBA of course is also runs on the 32 bit version of windows. -> Database triggers and features are are more oriented towards developers (such as a new data Pointer type in VBA - we never had a data pointer type in VBA. Too bad we did not, as the switch to 64 bits would have been seamless all well, when we jump to 128 bit computers, Access and VBA will be ready because we now have a true pointer data type). Other features will on the surface it looks like a giant leap forward for Access, and also for VBA. I was not aware of the table triggers - very cool. I like using triggers and

correct term. I am talking about Dbs to which you set a reference in the VBA references section. Secondly apologies for sort-of reposting this question, but I drew blanks last the Tools-> References section. As far as I know it is not possible to use VBA to compact and repair. I cannot find any way of removing the reference from the I have a reference set to "Menu.Accde" in the Tools-> References section of the VBA editor, then I uncheck the reference, Menu.AccDe still shows up in the project explorer Only those functions = 93can not be found = 94. But you can refresh the reference through VBA, by looping through the References. Especially when you have more than one reference that must the ambiguities from the programmer = 92s side, but that Access could refresh the reference for VBA, but failed to do that for (I assume) Jet Expression Service. After an Access.References except the one it was originally compiled with. The entire process can be automated using VBA and automation, so it is not as tedious as it sounds. Steve What old "Switchboard code." I also use late binding for everything but the basie three Access references (Access, VBA, DAO). Extra code? Not so much, but it is harder to code when you do is useful if there is a conflict with other libraries. . . just like you can call VBA.MsgBox() or simply MsgBox(). Of course, you know all that. The Help file DOES state