I have an app that launches a mdiframe (main with all menu options) at startup.

I saved the form as main2 with limited menu selections.

In the Activate event (for main mdi) I would like to check for @username and if not a regular user (ie. one that can access all

menu options) then I want to launch the main2 mdiframe instead.

Should I do this with Start_window, Create_dialog or some other way?

Also, can I make a whole form "view/read" only with one option or

do I code for this in each.

Thanks for any info.

Here is my recommendations:

1. If you only have two levels of access to the MDI Frame, then keeping two versions of the window (like you are doing) is the easiest way to go. Instead of having the application launch one of the MDI Frames, have it instead launch an invisible window that processes the user ID for access rights and then it performs a Start_Window to the appropriate MDI Frame. Make sure you close the invisible window when you launch the MDI Frame or the application won't shut down the way you expect it to.

2. If you begin to have several levels of access, then you probably want to develop a more sophisticated security/access scheme that dynamically updates your menus. Remember, it is better to hide or remove features rather than disable them so your users don't see what they are not supposed to have.

3. The question of Read Only windows came up just a few days ago. My response was to either create two versions of the window (one normal and one with all controls disabled), or to dynamically disable all controls when necessary. Another option, which escaped me before, is to disable whatever process allows the user to write (i.e. toolbar button, menu event, etc.) but also set the SAVEWARN flag to 0 during the CLEAR event. That way if they made any changes to the data when they closed or cleared the window, they won't get the "Would you like to save changes to the entry?" message which allows them to write the record anyways.

dbakke@srpcs.com

SRP Computer Solutions

So far this is what I did… I created a non-bound form that I named

START_MAIN, then in the activated event script…

---

DECLARE Function Set_Property,Start_Window,End_Window

uname=@username

BEGIN CASE

CASE uname=MAIN"

   x=Start_Window("MAIN_APP")

CASE uname=MAIN1"

   x=Start_Window("MAIN_APP1")

CASE uname=MAIN2"

   x=Start_Window("MAIN_APP2")

END CASE

x=End_Window("START_MAIN")

RETURN 0

---

BTW what is the difference between RETURNing 0 or 1?

As far as the "view" only form. Could I read all of the controls on a form then loop through to set the read/write property??

Thanks

Bruce

For controls and processes we 'disable' for specific users/processes instead of hiding them. This keeps the 'look' and feel of the window always the same without allowing access. We also have found this perferable to having multiple windows.

For VIEW ONLY we have a table of uses and their abilities then in the read event if the user can not update we note in the caption (view only), unlock the record (so other processes can use the record). Then in write we ignore if user not abled.

dsig

David Tod Sigafoos ~ SigSolutions

dsig@teleport.com

As I mentioned to Don …

For VIEW ONLY we have a table of uses and their abilities then in the read event if the user can not update we note in the caption (view only), unlock the record (so other processes can use the record). Then in write we ignore if user not abled.

Also .. during create of the window we disable any controls the user should not have access to (or hide if really necessary)

Be sure to set SAVEWARN as Don mentioned.

dsig

David Tod Sigafoos ~ SigSolutions

dsig@teleport.com

Bruce,

I'm assuming this is working for you. If not, let me know.

Returning a "1" simply means you are telling the event to chain to the next event. Returning a "0" stops the event chaining with the current event. In your case, it won't make a difference.

Finally, yes, you can loop through the controls and enable/disable on-the-fly.

dbakke@srpcs.com

SRP Computer Solutions

Thank you gentlemen,

Now where do I get the form's control list from?

I know I would like to … on ACTIVATE

Loop

.controlid-]ENABLE=0

until allformcontrolids do repeat

in the key control

unlock

Quick example??

Hi Bruce,

A list of controls on a form can be found in it's CTRLMAP property whcih returns an @Fm'd list of control names.

cpates@sprezzatura.com

Sprezzatura Ltd

World Leaders in all things RevSoft

As Carl mentioned CtrlMap for the window contains all controls on the form .. so all you want to disable are the edittext, tables etc maybe some buttons etc

Here is a little snippet which *should* work. I am doing this away from an OI system so you will want to check the position .. for control type ..

dsig

Subroutine No_No_Enable(a)

Declare Function Get_Property

Declare Subroutine Set_Property

$Insert Ctrl_Property_Equates

$Insert Logical

CtrlMap=Get_Property(@Window,CtrlMap$)

CtrlCnt=Count(CtrlMap,@Rm) + (CtrlMap # "")

Props=" ; Ctrls=" ; Vals="

For Pntr=1 to CtrlCnt

   Ctrl=Field(CtrlMap,@Rm,Pntr)

   CtrlName=Ctrl

   Begin Case

   Case Ctrl=BUTTON"

        Ctrls := @Rm : @Window:".":Ctrlname

        Props := @Rm : Enable$

        Vals := @Rm : False$

   Case Ctrl=yada

   Case Ctrl=yada

   Case Ctrl=yada

   Case Ctrl=yada

   End Case

Next Pntr

Set_Property(Ctrls,Props,Vals)

Return

View this thread on the forum...