Has anyone had any success in making a form readonly depending on the user. My users have a security level 1 to 5 and forms allow view or edit depending on matching security.

In Arev one can use WLOCKED but in OI can't find anything similar. I can use SET_PROPERTY to disable prompts but then can't scroll. I tried API SendMessage EM_SETREADONLY calls to disable prompts which is better because I can scroll. But this still allows data to be changed via Options popups etc and also has the downside that when putting the form into QBF mode it remains readonly without a load more coding.

I have around 80 forms that I want to add this security, ideally with a promoted event that I only have to code once. I can send the NOLOCKERR$ message to SYSMSG but that only display the message doesn't actually do anything.

Any ideas ? Surely you Arev conversion guys must have come up with something easy … please.

Carrie,

If you want a very sophisticated approach then you were going in the right direction already: a lot of code.

If you want a quick and dirty then simply put in your Promoted event for WRITE a Return 0 for users who are not permitted to write. The users will still be able to change data in the form and everything but in the end any attempts to write the row will fail.

dbakke@srpcs.com

SRP Computer Solutions

Don

Thank you for your quick response. I don't like the idea of the quick and dirty as it doesn't look as professional as Arev even. But if I do take this approach do you know the correct name for a promoted Write event that can be called before any form specific WRITE code. Some of my forms already have thier own unique code but it would be necessary to have a promoted event that was called before this and stopped the event chain.

With regard to the in built logic. It seems that the form processor must check if the record is locked and then set the form to readonly. So surely it must be possible to call this routine, whatever it is? From my investigations it looks like it is called before READ event but after LOSTFOCUS for the key field. Do you think Revelation Software may be able to answer?

Thanks.

Carrie,

Do you think Revelation Software may be able to answer?

Of course, but it really is a matter of will they answer. I doubt it unless you post this on the Works site.

Sprezzatura should have some good info on this as well.

The naming syntax for a promoted WRITE event pre-system would be:

AppName*WRITE.WINDOW.OIWIN*

dbakke@srpcs.com

SRP Computer Solutions

The best thing is than you install a routine MFS in your file, in the Write code it takes the value from @USERNAME allowing or not it writing.

Thank you for your help and comments. Looks like the promoted Write option for now.

Carrie

Sorry for the delayed response - I've been on holiday. I understand your problem completely. OI / Windows users are much more interested in security issues than ARev.

We have developed an entire security subsystem that does the following:

1. Permits entry of valid logins / passwords - usually one login for every user on the system.

2. Permits the assignment of a "security definition" to each user. This way multiple users may share the same "security definition" (thus minimising the system administrators job).

3. A fancy data entry screen that has a two part key being SECURITY_DEFINITION * FORM_NAME (where FORM_NAME is the actual name of the form stored in OI). This screen is clever enough to go and find that form, display all the menu options and allow the user to change each menu item from "green" (access permitted) to "red" (access not permitted) to "yellow" (read only access).

4. There is also a routine that must be called by the create event of each of your eighty forms which will go away and make invisible any menu options or make the screens read only as required according to which user has logged in.

These routines are also integrated with our very clever MDI routines which permit multiple "pages" of data to be displayed in a very nice windows style (have you hit the 114 control limit for a page yet?). Our users are able to specify which "pages" each user is able to see/not see/read only. The best part about these routines is that the code to handle all the security, opening / closing of MDI children is completely self contained and is able to call your special routines which may do all sorts of special processing dependant on each screen.

I have even completed most of the documentation…

I can tell you much more about these routines if you are interested. We have never sold them before, but so much work has gone into them (18 months development & testing now) that we would need to make a dollar or two out of them. If you are interested you can e-mail me at robert@ies.co.nz

View this thread on the forum...