Intro:
I have two separate forms.
frmABC
frmXYZ
I have frmABC in focus and I run a procedure that will "Tick" a checkbox called ChkConfirmed on frmXYZ.
Question:
What is the difference between these two ways of referencing another form?
1. Form_frmXYZ.ChkConfirmed = True
2. Forms!frmXYZ.ChkConfirmed = True
For some reason, only #2 works in this scenario. For me this is bewildering purely beacuse I have always used #1 and it has never complained before (when I say complain, I mean it does the job).
But, when I use #1 here and step through the code, it definitely runs the code but does not check any boxes...just nothing.
So, I would love to know the technical differences to help me understand when to use each one and in what cases.
EDIT:
Actual code snippet (as requested)
#1 Version
#2 Version
Access (I think >=97) treats Forms as a Class which means your forms are now a class module and can have all [class behaviors] including instancing.
Form_your_formname: you are referencing the Form via the Class module.
Forms!your_form name: You are referencing the form by its form name.
To access a form via Forms!form_name, the form must already have been loaded. Otherwise the form won't be reachable and you will get an error message "the referenced ...... not found"
On the other hand, Form_form_name can be accessed at any time as a class. It can have multiple instances like all classes do. Accessing an unopened form via its class module will cause the form is being instanced. This means Access will create a new hidden instance of that Form.
To test this try following.
Create a new form called: frm_test with a text box in it called: txt_id
go to your immediate window and try following code:
Edit forgot to mention. The test form hast to have a vba module attached to it then only it becomes a class module
Form_frm_test.txt_id = 1
Form_frm_test.visible = true
?Form_frm_test.hwnd
docmd.openform "frm_test"
?Forms!frm_test.hwnd
Now you will see two instance of the frm_test form and each of them will have their own window handle.
to answer your question:
But, when I use #1 here and step through the code, it definitely runs the code but does not check any boxes...just nothing.
its because your form is being instanced and its hidden.
So, I would love to know the technical differences to help me understand when to use each one and in what cases.
Technical explanation given above.
if your form is already loaded you can use the Form!form_name / form_name to access it. If you are instancing use the class name.
To be honest, I've never seen your 1st example used, ever... In fact a quick test in Access 2010 fails with an "Object Required" error message. All the code I've ever done uses the exclamation, which (someone correct me if I'm worng) works in all circumstances where you would need to reference another form for something.
Related
I created an object that is backed by a Foundry Form and I would like to provide a user to change the properties of that object. I linked the form to the object and created a title property that is a hidden/ derived value in the object creation form. A user can edit property a and property b and the title of the object will be ab.
When the user updates the object in the edit form the title does not update. Is there a configuration I need to change?
Yes, this is possible. There's actually two ways to achieve this, I'll list them in order of my preference:
Using an action
The modern way of achieving this is to use an action. Actions allow you to flexibly "intercept" events like writes from users and do extra actions (hence the name) or prevent things from happening. They are a fairly new feature in foundry.
The basic concept is that you write a little piece of code (a function on an object) that gets executed when the object is modified. The function can then modify the object further or prevent the modification.
This is very flexible, because it will allow you to automatically update the title of the object regardless of how and when the object was edited. You can also apply more complex logic to derive the title from e.g. multiple properties with fallbacks, or modify a property in a certain way before you put it into the title, et cetera.
The drawback is that this requires you to write some code.
On your stack, if you navigate to https://www.palantir.com/docs/foundry/functions/use-functions/#actions you will find an introduction on how to get started with actions. The example solves the exact use-case you're asking for.
Using form templates
Another approach that's simpler and does not require writing any code, but is much less flexible, is to use a template in the form. You can create a template form widget that's invisible, and is automatically populated by values from other form fields.
The advantage is that this is very easy and quick to set up, but the disadvantage is that it will only apply when the object is edited through the form, and you can really only do concatenation, not much else.
It sounds like this is what you attempted to do, and I believe this should work. If it doesn't, I would check the following things:
make the template visible to see that it gets filled out like you expect it to
make sure the template is set to store its response into the right property on the object
make sure the user is using the form to edit the object, not some other way (like editing the property directly in hubble)
I would like to know if it is possible in a Saved Query on MS Access to use WHERE clause getting value from a Form independent of MS Access installed language?
In a MS SQL QUERY WHERE clause that should be equal to a text in a form, I wrote it like this
= Form!Form_name!text_name
This work fine if all user have MS English version installed, however, this is not true in my case, as some users have a Portuguese version. In their version, the right way to call the same syntax should be:
= Formulários!Form_name!text_name
So, the problem is that Access does not recognize this considering language version. Due to this, if a user with Portuguese version try to run the query, it will pop up an insert box.
I've look throughout many sources but none could help me to solve this.
Thank you all in advance!
I can't test this as I don't have a portuguese version of Access but I avoid calls to form parameters because they are brittle. For instance the form has to be open or the query fails in wierd ways. If I must use a form's parameter I wrap the parameter in a public function (usually in that forms code behind). A public function usually gets picked up by intellisense even in the designer but a public variable does not.
My style is to synthesize a property with a private global scope variable and public get and set functions. Then in the designer you can call: get-myforms-property instead of Form!Form_name!text_name. When the form opens and closes I usually call set-myforms-property and set it to be equal to the actual form property.
In this way you also get the advantages of wrapping. For instance you can choose what value to return when the form is closed rather than just having the query fail.
Is it possible to raise built-in MS Access form events programmatically? I have a
feeling it isn't but thought I would check. (I am using Access 2003).
For instance, I want to do something like this within a private sub on the
form:
RaiseEvent Delete(Cancel)
and have it trigger the Access.Form delete event -- i.e. without actually
deleting a bound record.
Note my delete event is not handled by the form itself but by an external
class, so I can't simply call Form_Delete(Cancel).
I can understand your confusion -- I didn't explain any of the bigger context. Sorry.
Basically, the situation is I have an 'index' i.e. 'continuous-forms' form which is bound to a read-only query. The query has to be read only because it involves an outer join. But, I want to be able to delete underlying records from this form.
So my first thought was to do the deletion outside the form recordset, eg. using a delete query. And I was hoping to hook the standard Delete/BeforeDelConfirm/AfterDelConfirm events around this manual deletion routine by raising these events myself. But alas, this is not possible.
If the form itself handled these events, I could simply call the handlers (Form_Delete, etc), but my project has custom classes that handle form delete and update events (validation, confirmation, logging, etc.) for all the forms. (#Smandoli, it's not well-documented, I just discovered it a few months ago and use it extensively now -- maybe you know about it already -- you can set up external classes to handle your form events. See for example here)
Long story short, I found a workaround I'm satisfied with. It involves making the 'index' form a subform of another form that is bound to a recordset that can be deleted from. So the deletion can be done in the outer form using the standard Access form events, based on the selection in the inner form.
#Knox, I disagree in principle that being able to raise 'built-in' events yourself is difficult to document and maintain. Plenty of other frameworks depend on it. In practice, I agree with you, since we all have to work within the limitations of our tools and 'best practices' that evolve around those limitations. The blessing and curse of Access is its tight binding between recordsets and forms...
In common, there is simply no need to fire standard form events on your own, normally this shows a wrong understanding of form events in general (if not even events in general).
The form events exists to react on user interaction with the form or to notify the code behind of something that generally happens (like the Form_Load event). The event subs are there to react on these event - nothing more.
It is an often seen thing that people wants to execute event subs directly, but that's also a wrong way. There is a reason why event subs are in general declared as "Private" and not "Public", it should prevent calling them directly from outside the code module, but in fact you should also not execute any of them inside the same code module. Event subs always has to be called exclusively by their events, although it's possible to call them directly.
If an event sub has any code which should be executed also elsewhere then create a private or public sub inside the same module (depending on if you want to execute them from outside or not) and then call this sub from the event sub. If you think you must execute the same sub from elsewhere you can now also call the same sub. This is not a question of "it is possible to call the event sub directly", it is mainly a design question. You should always be sure that an event sub was called only by the event itself and never by any code. The problem when calling an event sub by code is that you can get in trouble very fast if you execute a code and also a real event executes it. In the end you get a big chaos of code which is very hard to debug.
It is, by the way, of course possible to call the event subs from a class module which has a reference to the form (which is needed if you use the class module to handle general events). You only would need to declare the event subs as Public and then you can call them with the form reference, but as stated above: Don't do that.
If a class module is used to handle the events then you can do anything here, you don't need the form code.
If a query is read only and you want to delete a record of a base table no event sub could help you. They are fired when the user wants to delete something which he can't do because it's read only so DoCmd does also not help you.
Like David said in the comment above, simply create a Delete button anywhere you want which can then read out the ID of the current row in the continous form and start a "DELETE" SQL command, then simply requery the continous form and you're done. You can also handle this in your standard class module because you can not only forward form events you can also forward control events on the same way. Create an Init procedure in your class module which takes all the controls from your form you want to handle with it any maybe additional the name of the base table in each continous form, then the class module can assign it to a standard "WithEvents" defined control variable of for example type CommandButton and save the base table name to a string variable. (Don't forget to set the OnClick event to "[Event Procedure]" in the Init procedure.)
In the Load event of your continous form where you probably initialize your class module you can then forward the base table name and the delete button control to the Init procedure of the class module which then can handle the deletion on a very generic way by starting a DELETE query on the base table and requery the form because it already has the form reference also. No need to call any event procedure.
Last but not least: Maybe there are frameworks which allow you to raise events directly but in common I would say that the creators of such frameworks also didn't understand the purpose of event procedures. If you have ever created an own event in a class module of your own you will see that they also cannot be raised outside the class module. Of course, you CAN create a "RaiseEvent" sub on your own to call them externally - and in fact, in case of own events it can make sense in some scenarios. In case of form (control...) events they should inform the code about something happened and there should be a reaction now. If you use events in own class modules you would normally also create a "WithEvents" variable in the outside module to get informed when an event happened in the other class module. An event should make it possible to make the module objects independent of each other. The module with the event will only raise the event and it doesn't know if anyone is listening to it or react on this event. It informs "the world" that there was something which happened in the class module, nothing else. Like a radio station which sends the daily news "to the world" but it doesn't know about if anyone listens to it. Normally, no listener of the radio station would go to the radio station and reads his own news for other listeners. Only the people at the radio station decides what to send and when. Same story.
I have a public function in an Access form
Public Function PopupProcess() as long
MsgBox Me.ActiveControl
PopupProcess = 1
End Function
When I call
eval("forms('MyForm').popupprocess")
it shows a message box 2 times. Does anybody know why it does that?
I Have Access 2003 with SP3.
EDIT : Main idea is to call function from that form for Custom Commandbar control OnAction.
Maybe you have better way to call function from a form for commandbar control.
This is a very long standing bug that’s been around since the days of access 97, (about 4-5 versions of access).
The solution here is to NEVER use the forms qualifier, simply place the following in your on action event, and you’ll be just fine
=PopUpProcess()
Note that you must precede it with=, and the suffix must have the brackets ()
Keep in mind that you can actually use behavior to your advantage. The function that runs is going to be from the form that currently has the focus on the screen. That means you can have different forms with the same name of the function, and whichever form has the focus, that function with that name will run from that forms code module.
Even better, if one of the forms does not have that function as public in the forms code module, then the function in a standard code module is used. So you might have nine forms, that all use the standard one function in the main standard code module. However, the 10th form might need to run special code, so you simply place that function code in the form’s code module as public and it will run in place of the public on in the standard code module.
This approach allows you to build a single custom menu bar that applies to many different forms, but those many forms will run different code on from that custom menu bar. This also encourages you to place the menu code in the form it belongs.
So to solve your problem, simply don’t use a form’s qualifier, and use the above format.
Note that you can pass Parameters from those functions also, for example
=PopUpProcess(‘hello’)
And then declare the function as:
Public Function PopUpProcess(strParm as string)
Keep in mind that the function and syntax and all of what I stated above also applies to when you use the on action in a ribbon for access 2007.
No idea. What happens if you call it like this?
Call Forms("MyForm").PopupProcess
Try using the CallByName function, instead of eval, to call your function. It should only fire your function once, and it will still allow you to parameterize the form name and the function or sub name:
CallByName Forms("MyForm"), "PopupProcess", VbMethod
While I'm developing my MS Access application, I open it with shift click. When an Error occurs, that is not trapped (by ON ERROR ...), a message box pops up informing me about the error. This is a good thing.
When a user open my application, he does't shift click, and an appropriate Start Form opens. However, now untrapped Errors don't show up, the application behaves as if the user clicked the Stop Button on the message box. I don't want this behaviour.
Is there an option / property / variable that provides the same behaviour in the production code (preferably even when the application id converted to an mde) as in development, i.e. show a message box for every untrapped error? Or is it neccessary to trap errors in every single event routine and pop up a message box by program?
It turns out, this is a side effect of setting the AllowSpecialKeys property to False. This can be done programmatically, but I did it in the menu under Tools > StartUp.
Since this property allows the user to open the code editor, it kind of makes sense, but the relationship of the phenomen described to this option was puzzling for me.
Does this mean, that if I want to hide my code, I need to write all those error handlers? Or is there one central place (like a main method in Java) where I can invoke an error handler. Alternatively, could I allow specical keys and just protect the code with a keyword?
You can create your own error handler and add it to all procs, subs and functions. You have this very nice MZ Tools VBA add-on that allows you many thing such as adding line numbers to your code, "preprogramming" your error label, etc.
If you are smart enough, you'll be able to use this add-on to generate a standard "error management" code displaying things such as err.number, err.description, and the undocument erl value, which is the number of the line where the error occured (you must first have your lines numbered before being able to get this value).
EDIT: I just opened this question on a similar subject.
As alluded to, MZ-Tools 3.0 is a great tool to aid in quickly adding error handlers. Also remember that errors which occur in procedures without error handlers "bubble up" to the last-invoked On Error statement. (And if no statement exists you get the little gray debug box.) The net effect of this, is that you can do minimal error handling by simply adding error handlers only to those procedures which are Public (or Friend) or called by event. This will make sure you always have at least 1 "top level" error handler invoked. If you want to add special handling to your private procedures after that feel free. If not, when an error occurs in them they will "bubble up" to the top level error handler.