Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
Hi,
I have an app that is supposed to be the frontend to a simple database.
There will be a lot of people working with this who wil be assigned one of three roles
=> According to their role, they will have RO or RW access to the fields.
==>> I am just creating three sheets, one per role
==>> For all the fields that people can edit, they shall get input_boxes
==>> For those which they can only view, they shall get text_boxes.
That way, though, I cannot make it dynamic (in case the association_structure changes) because from a text_box, I cannot easily make an Input_box. I would have to create both and then decide dynamically which one to show which means a lot of variables.
=> Is there a way I can lock input_boxes and make them read_only? That would be an easier way to switch between the two and I
would need only one sheet for all three roles
(I just notice there is a radiobutton in the dialog, but that doesn't help me because I cannot use an expression to switch that.
=> Can I somehow use the edit_field with the "customized" option of this radiobutton?
Thanks a lot!
Best regards,
DataNibbler
Hi,
I am just trying to put two Input_Boxes on top of each other. I have a variable specific for this field I am testing to say either 'RW' or 'RO':
- When it says > RW < I want to have one InputBox with no input_restrictions and a green label;
- When it says > RO < I want to have an InputBox with the >ReadOnly< option and a grey label.
There seems to be a bug there, however. It doesn't seem to work. The option I select for the input_restriction - either "none" or "ReadOnly" - seems to be valid for both copies ... I keep switching the value of the variable, but the InputBox always seems to have exactly the other option activated.
Can anybody confirm this?
Thanks a lot!
Best regards,
DataNibbler
Yes, those properties are not linked to your input box but to the variable (check in the document properties sheet "variables"). So maybe you will have also to duplicate your variable, the second one refering to the first one.
Hi Vince,
that is an alternative worth thinking about. I was thinking of having two different objects - an InputBox and a textbox - but having two variables per sheet will be much less of a load in terms of qvw-size and performance.
Thanks for the hint!
Best regards,
DataNibbler
P.S.: Hmm, but I cannot (optionally) show one of two different variables in an InputBox as I cannot enter a formula or a condition - so I will still need two objects. Well, that way it will still be easier as I can just use a copy of the InputBox and I won't have to worry about it looking the same and being in the exact same place ...
Or is there any way I could show one of two alternative variables in one InputBox?
Hi DataNibbler,
it could be that the restriction is on the variable itself and not on the inputbox like the OneAndOnlyOne option for the listbox which restricted the field and not the listbox.
I seems that your task it's quite difficult. Maybe you could two different variables for the user input and a third one decided which wille be applied. Or if your user use the IE or the fat-client you could try to manipulate the user input with macros, perhaps in this way:
set v = ActiveDocument.Variables("Variable1")
v.ForceContent "123",123
- Marcus
Hi Marcus,
I go with the first approach. I guess the users will all need to use the client, but I'll worry about that later. For now - I do have one other variable per field already which says either > RW < or > RO < to define whether that user can only view or also edit that field. Depending on that, I can show one of two alternative InputBoxes (in the exact same place), one with one field_variable which is set to > no restrictions <, the other one with a field_variable which is set to
> ReadOnly <
That way, there will be a lot of objects and a lot of variables in that app, but that way I can maybe do with just one input_sheet. I just have to take care that all the variables show just what is in the table and are always reset to that value in case someone else has entered something else.
There remain some hurdles, that's what makes this interesting...