I tried to use the workaround where we simulate it with a headerless collapsable section, using a variable to control the collapse state.
However it seems that there is no way to make a variable based on user's properties such as group membership, userid, etc.
Ideally I would reference the validity of the action parameters to reuse the permission there.
Is there any way to implement this currently?
If you create a string array variable in Workshop, you can initialize it to Multipass attributes such as group membership:
https://i.stack.imgur.com/mAtIt.png
https://i.stack.imgur.com/PUhlm.png
Section visibility is controlled by boolean variables, so you then you want to pass this string array into a Function, evaluate the groups as needed within the Function, and then return a boolean variable that will control the visibility of your section as needed.
https://i.stack.imgur.com/Q3uq7.png
Related
The app I am working on has hidden input variables set on initial load of the page. The variables need to be accessed across all pages. The reason for not converting these to session variables is the user can open another browser with different parameters and passing those value as hidden inputs make it work without any issue. What is the best possible alternative so as to get rid of these hidden inputs..I tried converting all variables into a Structure, but again the structure needs to be posted as part of form submission to make it available to subsequent pages.Another disadvantage of this app is use of frames.I don't have any code to post.
It sounds as if you want different browsers instances which are associated with the same web session to maintain their own distinct sets of data. Doing this by passing form or url variables around seems like a bad idea.
One approach that you could use would be, onSessionStart (or as required), create a structure in the users session to hold instances of the data. For example
session.data = {
someRandomKey: {
valueA: 42,
valueB: "Porridge"
}
}
Then just pass someRandomKey as a hidden form field or querystring parameter. Now, when they submit the form to update variables you use the id from the hidden form field to find the appropriate structure from session.data.
When the user needs a new instance of this form, give them some way, like a link or button, that creates a new unique key, inserts a struct in session.data with this key and populates it with whatever defaults are needed then loads the form passing along the new id as a hidden form field or querystring param again.
I am writing a query that fetches the permissions for a user on our website. It first checks to see if there are any overrides for the permissions, then checks the permissions for the users role on the website, and if those are null it's defaulted to 0 (AKA no permission.. the other values would be >1).
I figured coalesce() would be the best choice here as I could do something like
coalesce(override, role, 0);
Where override and role would be the fields in the database.
However, if it was indeed an override permission, I need to know because I display an icon indicating it as such. Is there any way I could determine this in a clean manner?
Add a separate column with boolean for an override.
select coalesce(override,role,0), (override is not null) as override_enabled
I'm creating a navigation form where some of the navigation buttons simply apply filters to the subform. Problem is right now each option is exclusive, i.e. I can select staff either by branch OR by job title. How can I make the options NOT exclusive so that I can apply multiple filters at once?
EDIT just to add. I have no knowledge of VBA so I'm trying to do this using the graphical interface and of macros. If it can't be done using these tools then fine, I'll find a different solution.
If you replace the .Filter property on a form (or subform) with a new value then the previous filter goes away. If you append a new clause onto an existing .Filter string, e.g. by changing...
[Branch]="Main"
...to...
[Branch]="Main" AND [Title]="Manager"
...then the new filter applies both criteria.
This solution requires a moderate amount of VBA (I can't think of a solution that wouldn't require it). Store the user's choices in module level variables and then apply your filters using a master ApplyFilters subroutine.
For example, give each checkbox an AfterUpdate event. This event will do 2 things:
Set the module level variable with the user's selection
Start the ApplyFilters sub
Since all the user's choices are now stored in module level variables, the ApplyFilters can see them all. It will:
Take all the module level variables and creates a master string (hint, if you need a Placeholder, use 1=1)
Apply that string as your subform's filter.
Other notes:
Accessing your subform's controls from the main form is simple. To change your subform's filter to the string NewFilter, try:
Forms!MyMainFormsName!MySubFormsName.Filter=NewFilter
So how can I pass a value from one form to another? For example: The user select's an organization from a list and this opens up a trip form that allows a user to enter various information regarding the trip. At one place I would like to add another little pop up form where they can enter contact information (just a name and phone for POC) of the organization they are visiting.
So when that initial form opened from the selection screen it has two IDs that are simply hidden in text boxes (one being the tripID, and the other being the OrgID), so how do I pass these to the second little pop up form so that the contact information has the relative IDs with it.
Thanks.
The best approach in these cases is not to attempted to pass a bunch of variables. It is too much code, and is inflexible. For example, if you need to pass two values, what happens over the years when that requirement grows to 5 values? Trying to maintain and pass a whole whack of values is too much coding work.
Keep in mind that each form in ms-access is really a class object that you can manipulate in code. So, use a object approach here and you find you not only write less code, but your code will be more clean, more modular, no need for global vars, and code you write can often be re-used between different forms.
Here is how:
In general when one form launches another form in the 2nd form in the forms on-open event (in fact, you can even use as late as the on-load event) you can pick up a reference to the PREVIOUS form object. In other words, you can use a object approach here.
At the forms module level, for form I declare a form object as:
Option Compare Database
Option Explicit
dim frmPrevious as form
Then, in the forms on-load event, we go:
Set frmPrevious = Screen.ActiveForm
Now, any code in our form can FREELY use code, events, even varibles declared as public from that previous form in code.
So, if you want to force a disk write of the previous form, and re-load of data.
frmPrevious.Refresh
If you want to set the ID value, then go:
frmPrevious!ID = some value
And, note that you can even declare form previous as a PUBLIC variable for that form, and thus if you two forms deep, you could go:
frmPrevious.frmPrevious!ID = some value
So, simply declare a forms object in EACH forms code module (or at lest the ones where you need to use values in code). The above means any code has a ready made reference to the previous form object. Functions declared as public in a form will become a METHOD of the form, and can be run like:
frmPrevious.MyCustomRefresh
or even things like some option to force the previous form to generate and setup a invoice number:
frmPrevous.SetInvoice
or
frmPrevious.SetProjectStatusOn
So not only can you shuffle values and data back and forth, but you can easily execute features and functions that you build in code for the prevous form.
In fact as a coding standard, MOST of my forms have a public function called MyRefresh.
Note that the beauty of this approach is that you can thus read + use + set values from that previous form. This allows your code to not only receive values, but also set values in that previous form. So this approach is bi-directional. You can shuffle data and values back and forth between the forms. The other advantage here is you NOT restricted to just variables, but can use fields, control values (events, properties) etc.
This approach means that much of the previous form is now at your fingertips.
So don’t try to pass a whole whack of variables. Pass a reference to the form and you have a nice ready made object at your fingertips and it makes this type of coding problem a breeze.
The usual way would be to reference the textboxes in the initial form from the popup form, like this:
Forms!frmInitialForm!tripID
Forms!frmInitialForm!OrgID
However, this tightly binds the popup form to the initial form, so that it cannot be used anywhere else in the application.
A better approach is to use OpenArgs:
DoCmd.OpenForm "frmPopup", OpenArgs:=Me.tripID & ", " & me.OrgID
This places your two values into a string, which is passed to the popup form. You can then parse the two values out of the OpenArgs using the Split function.
For more info about passing parameters using OpenArgs, see:
http://www.fmsinc.com/free/NewTips/Access/accesstip13.asp
This one could help
MS Access: passing parameters from one access form to another
I have an Access form where each record has some info that is computed on the fly. I'm using the Form_Current() event; each time a record is selected, I compute some information and change some form controls to reflect it, based on the record's ID.
I want to print a bunch of these records. However, in this situation the Form_Current() event isn't being triggered and the printed records lack that dynamic information.
Any ideas?
Make a query that computes the information you need as the source of your report. You can use vba functions if needed for complex calculations.
In a comment, Luis Oliveira asked:
My function was in the Form itself,
which is why I couldn't call it from
the SQL query, I suppose?
By default, functions in a form are private. If made public they can only be called when the form is open, as in Forms!MyForm.PublicFunction(). I would advise against that. Instead, move the function to a public module (which may require revisions to remove references to form controls/fields).