I have a form with two chevrons (video fwd/back buttons), to page through days of the week.

On the click event of each - I go off and select a bunch of data and display it

what happens is that people will press a button 7 times to get to last week, and the code is lost / stuck until it processes (unnecessarily) the 6 days that it's effectively walking through

Is there a programatic way to check what events are Queued? and cancel them? so that I can can the previous 6 which are stacked up and run just the last one?

tia!

I use a user-defined property, for example @BUSY, to flag that the processing is active.

isBusy = Get_Property(CtrlEntId, '@BUSY')

if isBusy then

return 0

end

unused = set_Property(CtrlEntId, '@BUSY', 1)

* Do processing here, including Yield() statements

* ….

Set_Property(CtrlEntID, '@BUSY', 0 )

return 0

Colin,

       I've created this example to simulate your example form. Instead of the chevrons, I've used a forward and back button that triggers the TIMER event when pressed. The user has the chance to click the button multiple times to skip back/forward instead of loading each record. The TIMER event would load the record and take into account the number of times the button was clicked so it can skip to the correct index.

      Using the TIMER event with the delay should accomplish what you're after and is easier than working with the event stack queue. Please let me know if you have any questions regarding the code below.

This is the commuter module code for my sample form

action_delay=200 ;*execute the Timer event after action_delay mSec. 

Begin Case

	Case Control = "TIMER_TEST"

		Begin Case

			

			Case Event = "CREATE"

				x=Set_Property(@window:".LBL_CURRENT","TEXT",0)

				Case event="TIMER"

				

				x=Get_Property(@window:".EDL_DIRECTION","TEXT")

				curr_pos=Get_Property(@window:".LBL_CURRENT","TEXT")

				num_clicks=Get_Property(@window:".EDL_CLICK_COUNTER","TEXT")

				If x="BACK" Then 

					curr_pos=curr_pos-num_clicks

					*Simulate a long running operation using Delay subroutine

					call Delay(3)

				End

				If x="FORWARD" Then 

					curr_pos=curr_pos+num_clicks

					*Simulate a long running operation using Delay subroutine

					call Delay(3)

				end	

				x=Set_Property(@window:".LBL_CURRENT","TEXT",curr_pos)

				x=Set_Property(@window:".EDL_CLICK_COUNTER","TEXT",0)

				

		End Case

	

	Case Control = "BTN_BACK"

		Begin Case

			Case Event = "BTN_BACK"

			Case Event="CLICK"

				call Set_Property(@window, "TIMER",  0:@FM:action_delay) ;*

				x=set_property(@window:".EDL_DIRECTION","TEXT","BACK")

				x=Get_Property(@window:".EDL_CLICK_COUNTER","TEXT")

				x+=1

                x=Set_Property(@window:".EDL_CLICK_COUNTER","TEXT",x)  

				

			End Case

				

	Case Control = "BTN_FORWARD"

		Begin Case

		

			Case Event = "BTN_FORWARD"

			Case Event="CLICK"

			call Set_Property(@window, "TIMER",  0:@FM:action_delay)

			x=set_property(@window:".EDL_DIRECTION","TEXT","FORWARD")

			x=Get_Property(@window:".EDL_CLICK_COUNTER","TEXT")

			x+=1

			x=Set_Property(@window:".EDL_CLICK_COUNTER","TEXT",x)  

			   

				

				

		End Case

End Case

Martin,

        Sorry about the name mix-up in my prior response.

                             Barry Hausner

Easier way would be to disable the button when clicked, before you start the stuff to populate ,then re-enable at the end.

Colin

I don't think this was what Martin was after. In his example he says the user wanted to get to the 7th record using forward and backward chevrons (buttons). Since the 7th record isn't very far the logical action for the user is to click 7 times (assuming no record is displayed). The problem is the display (or record load process) moving between records 1, 2, 3, 4, 5, and 6 is slow.

So if he knew the user clicked 7 times, how could record that information before his event code executed? I.e. how could he check the event queue and see the pending click actions.

Barry's example with the single delayed TIMER event will allow the user to click the button numerous times so the form can record the number of clicks. The TIMER event then can gather the number of clicks and load the desired record instead of having to display each record one at a time.

In the spirit of Colin's post ( let the gui prevent the user from causing the issue) , you could provide a calendar, hScroll or other visual control that lets the use jump directly to the data they desire.

Cheers guys - I see better options than what I do and I will trial them all.

Greatly appreciate your help

Couldn't resist :) - new blog post.

The Sprezzatura Group

The Sprezzatura Blog

World leaders in all things RevSoft

Andrew - good morning

what a great article - from me Cheers for kindly sharing

View this thread on the Works forum...