Hello group.

Somebody know, as enabling, to disable or to modify the events WRITE and DELETE?. I try to make it with QUALIFY_EVENT, but it doesn't work me. Apparently alone it applies for controls, and it doesn't stop Windows. Or is there some form of making that the QUALI_EVENT works for Windows events?

Thank you for any tip or help.

Luis,

Based on what you are trying to do, just return a 0 to prevent a WRITE or DELETE event from being executed. QUALIFY_EVENT is used for redirecting one event to another so I don't think that is what you are after. Make sure, however, that you are returning this 0 in the procedural event and not the QuickEvent.

dbakke@srpcs.com

SRP Computer Solutions, Inc.

Luis:

I think what you're trying to do is to prevent WRITE or DELETE events from firing due to some reason…an error or because the user is prohibited from doing so. The easy way is to place a script ahead of the event.

From the main control of the form, select Events and from the dropdown select the event..Write / Delete Row, etc.

Click the Script button and make sure that the script ends with a Return 0.

You might add a message to notify the user of the activity. If you want to really make it work smoothly, make sure that SAVEWARN is set to false so they won't get prompted for the save:

DECLARE SUBROUTINE SET_PROPERTY,MSG

DECLARE FUNCTION GET_PROPERTY,MSG

Temp=Get_Property(@WINDOW,"SAVEWARN")

If Temp=1 then SET_PROPERTY(@WINDOW,"SAVEWARN",0)

null=MSG(@WINDOW,"Save Record Disabled ..")

RETURN 0

HTH

Don Miller

C3 Inc.

Hi all

Well I might be suggesting the obvious with this one but sometimes that is exactly the help I'm looking for.

It sounds like what Luis needs is FORWARD_EVENT()

I don't have any help on QUALIFY_EVENT - it sounds like another one of those undocumented features. If someone wants to post how it is supposed to be used, I'd be grateful.

The following is some example code of how I use FORWARD_EVENT. Some of the code might be unnecessary (redundant) but it should be enough to start with.

* in the write event of the form.

* if you have a save button, make it execute the form write event.

* (see help on post_event)

	error =0
	Gosub PRE_SAVE
	If NOT(error) Then
		void 	=Set_EventStatus( 0)
		err_line=SET_PROPERTY(@WINDOW, '@ERROR', 0)   ;*initialise @ERROR
		* execute the write
		Call FORWARD_EVENT()
		error2=Get_EventStatus( err_code)
		If error2 Then
			* something went wrong with the write, like locked record maybe
			err_line=SET_PROPERTY(@WINDOW, '@ERROR', 1)    ;* set @ERROR
		End Else
			Gosub POST_SAVE
		End
	End Else
		* don't execute the write
		void 	=SET_STATUS(0)
		err_line=SET_PROPERTY(@WINDOW, '@ERROR', 1)
		status 	=GET_STATUS(err_code)
	End
RETURN 0
PRE_SAVE:
	* do some validation
	* if not(valid) then
	*  error=1
	*  set focus on dodgy control if you want.
	* end
RETURN
POST_SAVE:
	* update a log file or what ever.
RETURN

Janet,

Essentially your code does what the two Don's have suggested, i.e. return a 0 if you don't want the event to complete.

QUALIFY_EVENT is not undocumented, but it can be mysterious. It is used with the Send_Message function. It can be executed for one of two purposes:

1. Routing a specific event to another event.

Sometimes you want all events of a particular type to be routed to a single place for ease of management. For instance, we like to manage all of our WINMSG events at the promoted level. However, OpenInsight doesn't automatically do this with WINMSG event though I have created a promoted WINMSG event. I also have to make sure that all windows qualify their own WINMSG event to be routed to my promoted WINMSG event. Then I can track all event processing in one place like a commuter module. Here is a code sample:

Send_Message(Ctrls, "QUALIFY_EVENT", "WINMSG",

–] 1:@FM:6:"*":@APPID:"*WINMSG..OIWIN*")

The "Ctrls" is a dynamic array of all the controls on the form. Each control must be qualified, therefore a loop is used to go through each control. The third parameter indicates what local (i.e. window specific) event I want to re-route. The fourth parameter indicates what event I want the local event routed to. In this case, I am requesting that the local WINMSG event be routed to the promoted WINMSG event.

2. Triggering OI to capture a Windows Message.

The Windows operating system communicates internally with all running applications through a large array of messages. If your application is not programmed to "listen" for these messages then they are simply ignored. Revelation has pre-programmed OI to listen for a great deal of these messages so our applications can function properly while running. For instance, if OI wasn't programmed to listen for the message that indicates the pressing down of a keystroke, then our editfields would never display a single character. These messages form the underlying basis for our events: CHAR, CLICK, DBLCLK, etc.

There are a lot of messages, however, that Revelation has not programmed OI to listen for. To do all of them would be impractical and probably not very useful. Nevertheless, experienced programmers have been asking for ways to expand the functionality of their applications beyond the normal capabilities. Context-menus and other right-click operations is a great example.

In order to help these programmers accomplish this task and to avoid the need to create a new event for OpenInsight each time, Revelation created a catch all WINMSG event. The secret to using WINMSG, however, is to tell OI to listen for the Windows message you are interested in. This is done with the QUALIFY_EVENT message. It has a slightly different syntax than the other use of this function:

Send_Message(@Window, "QUALIFY_EVENT", "0x0020", 1)

The third parameter tells OI which Windows message you want to listen for. This is often represented in hex (as above) or can also be represented as decimal number (i.e. "32" for the above example.) All Windows messages have a numerical value. You have to purchase a Windows API (Application Programming Interface) manual to get a list of these messages. The fourth parameter is simply a boolean flag to tell OI to start the listening process. A zero (0) would turn this off.

In the above example, "0x0020", is the Windows message WM_SETCURSOR. This message essentially tells an application whenever there is mouse activity going on. This provides us a means of trapping the mouse and any type of clicking that is going on. Our WINMSG event is then fired and in that event code we can exercise whatever functionality we want. Remember, however, that with the first purpose of QUALIFY_EVENT (at least in our example) we have routed all local WINMSG to our promoted WINMSG. This means that I only have to worry about developing functionality in one location of my application which makes the chore a whole lot easier.

Anyway, I hope this primer helped provide somewhat of an explanation of QUALIFY_EVENT. It takes a bit of tinkering to understand it and make it work…but it is worth the effort.

dbakke@srpcs.com

SRP Computer Solutions, Inc.

Thanks to all.

It is certain to say that when putting a "Script", in the corresponding events, it makes the function of the "Pre_Event", and therefore if I don't call to "Forward_Event()" it doesn't make the task for default.

But what I need is to disable or modify the events of the Window (WRITE, DELETE, …)in general form if the Window and user's permits require this way it.

I have a function, in all the "CREATE" events in my Windows, where I initialize all type of restrictions, one of them is to disable or to hide some controls.

For I finish: if I could make work the "QUALIFY_EVENT", for the events of the Window, alone it would modify my function, and not each one in my forms or windows. For that would write a generic code for the event that wants to modify in a window " READ_ONLY ", and alone it would be enough to direct the event corresponding of any window toward the generic event of " READ_ONLY ".

Good, I wait to have given myself to enteder, and seriously thank you for any help or comment.

Luis

I think you will need to put code in every event that you want to restrict. Even Donald says when he uses Qualify_Event he still needs to write code in each event to send the event (eg WRITE) to the custom one he wrote.

If you use my way, you still need to put code in every event. You could write a function that would return true if the user is allowed to execute that function and put the forward_event in the event script for the true case.

Eg a function with the following kind of parameters (sounds like you already have one)

IS_ALLOWED(user_id, form_id, action_id, mesg)

so your PRE_SAVE: validation would include something like

user_id=

form_id=MY_FORM" ;* where MY_FORM is the name of this form,

* you could possibly extract it from @WINDOW

action_id=WRITE" ;* ie the name of the event that you are calling it from - again I think there is an @Variable or CTRLENTID that would give you this or you could write it in.

mesg='

If IS_ALLOWED(user_id, form_id, action_id, mesg) then

 null

• FORWARD_EVENT() is allowed

end else

 error=1   ;* forward event not allowed. 

 error_mesg=mesg

 gosub display_message  ;* write some code for this...

end

Scott

If consoladating your event code is the goal then creating a promoted event would be far far better.

dbakke@srpcs.com

SRP Computer Solutions, Inc.

Excellent synopsis - Thank You Don

Hi Donald

I think you could be right. I worked on a pick system where every single bit of input and every write went through a single input routine and a single write routine. It was great for handling instant menu jumps to other bits of the system and file lookups and preventing writes or customising them (we had built our own version of indexing).

I wrote about forward event because I know how to make that work where as Luis seems to be having problems making qualify event work and since I haven't used it, I couldn't suggest how to make it work.

Would I be correct in thinking that if you wanted to promote your form write event to some generic write subroutine you would need to put some code that uses Qualify event in the write event of each form to force the form write to use the "promoted" code? How/where would you put the "promotion" code to make it work?

Janet

Janet,

There is no reason that you have to include Qualify_Event in a promoted event.

To create a promoted event, create the events you want on a standard window. The copy the SysReposEventExes record to a promoted name,e.g.

@DBID*WRITE.WINDOW.OIWIN* for a window type event

or

@DBID*LOSTFOCUS..OIWIN* for a control type event on all controls

or

@DBID*LOSTFOCUS.EDITBOX.OIWIN* for a control type event on Editbox controls.

Then delete the events from the window and replace with a Return 1 event.

Note - you may want to copy the source as well for later use !!

Hope this helps

Simon

Rebus Software

Hi Simon

I'm not sure I understand what you wrote, I get the impression that what you suggest is I write my shared event and then overwrite all the related events eg all the lostfocus events with the shared event. What happens when I change the code in the shared event?

Do I have to do that copy again? In that case wouldn't it be better to write code in the form events to call the shared event code? That way if I change what happens when the shared event is processed I only need to make the change in one place?

Scott

Janet,

Simon was not suggesting that you copy the shared code to all the other events. However, until you get a primer on Promoted Events some of this discussion will be a little difficult to understand. As usual I always recommend Sprezz's SNL article on the subject. Here is a Revelation post where Sprezz created a link to the actual article on their website. Once you've read this then I suggest you come back with any follow-up questions. This is definitely worth the effort.

dbakke@srpcs.com

SRP Computer Solutions, Inc.

Thanks Don,

Janet,

Basically (I have not read the Sprezz link), you copy the code that you want to be accessed by all events into the promoted event, preferably a procedure call which means all changes can be done without further 'promotions'.

Then within a single event, code in the event will still be executed, followed by the promoted event if you complete your event with a Return 1 or stop at that point if you complete your event with a Return 0.

Often a good way is to use a success flag on the return.

Any further queries ??

Simon

View this thread on the forum...