Please think for me (OpenInsight Specific)
At 22 APR 1998 02:08:44PM Oystein Reigem wrote:
I have blisters on my cortex for thinking too much today. Could somebody please help me with the following:
(1) I have an edit line with a GOTFOCUS quickevent, and the quickevent sometimes does not run. What are the likely reasons? I do a lot of handling, perhaps of the dodgy kind, on the previous field - the key field.
(2) The aforemented GOTFOCUS quickevent sets focus to the next control again. It's just there to make sure the edit line is skipped. I need just the default value, which is fixed. I don't want the user to mess with the content. Are there better methods? I'm sure there are but I cannot think right now.
- Oystein -
At 22 APR 1998 02:23PM Blaise(Revelation) wrote:
Hello Oystein,
If you do not want anyone to touch the data in that field, why don't you disable the edit line? The quick event in that field doesn't allow the edit line to have focus anyhow. Just make sure the tab order is correct.
Good luck…
Blaise
At 22 APR 1998 05:09PM Don Bakke wrote:
Oystein,
(1) I have an edit line with a GOTFOCUS quickevent, and the quickevent sometimes does not run. What are the likely reasons? I do a lot of handling, perhaps of the dodgy kind, on the previous field - the key field.
Two possibilities:
1. You also have a scripted event handler that returns a zero under certain conditions
2. If you are programmatically setting focus to this control, make sure you use the syntax:
rv=Set_Property("SYSTEM", "FOCUS", @Window:".EDITLINE")This guarantees that the GOTFOCUS event gets launched. Using the syntax:
rv=Set_Property(@Window:".EDITLINE", "FOCUS", True$)won't do it.
(2) The aforemented GOTFOCUS quickevent sets focus to the next control again. It's just there to make sure the edit line is skipped. I need just the default value, which is fixed. I don't want the user to mess with the content. Are there better methods? I'm sure there are but I cannot think right now.
I would suggest disabling the control and getting the default value some other way, like a function call, that is accessed from the LOSTFOCUS event of the key field.
At 23 APR 1998 05:27AM Oystein Reigem wrote:
Blaise,
But would the default value work when the field is disabled? I think I had problems when I implemented this (must be several years ago now). I think this might be one reason I ended up with my current solution. I see that Don B suggests setting the default value from somewhere else, e.g from the key field lostfocus, and that may be because he knows the default value will not work.
- Oystein -
At 23 APR 1998 08:23AM Oystein Reigem wrote:
Don,
(1) I have an edit line with a GOTFOCUS quickevent, and the quickevent sometimes does not run. What are the likely reasons? I do a lot of handling, perhaps of the dodgy kind, on the previous field - the key field.
Two possibilities: 1. You also have a scripted event handler that returns a zero under certain conditions
No. The edit line has exactly one handler, and that is the GOTFOCUS quickevent.
2. If you are programmatically setting focus to this control, make sure you use the syntax: rv=Set_Property("SYSTEM", "FOCUS", @Window:".EDITLINE") This guarantees that the GOTFOCUS event gets launched. Using the syntax: rv=Set_Property(@Window:".EDITLINE", "FOCUS", True$) won't do it.
What's really wrong with the latter? Should they not be equivalent? In my app there are 27 user events and SPs with that syntax! Eeeek!
Well, I changed all Set_Property…"FOCUS" in the vicinity without getting further. (None of them set FOCUS to that edit line, and only one of them could have been executed, and when it did get executed it succeeded.)
My next thought was that something could be wrong with the SP I use in the GOTFOCUS quickevent. I've appended it just in case. (Ah - never mind! As you see below I have no use for it any more.) (And I know for certain that it doesn't run so it can be as rotten as it likes. It simply cannot be that SPs fault???)
(2) The aforemented GOTFOCUS quickevent sets focus to the next control again. It's just there to make sure the edit line is skipped. I need just the default value, which is fixed. I don't want the user to mess with the content. Are there better methods? I'm sure there are but I cannot think right now.
I would suggest disabling the control and getting the default value some other way, like a function call, that is accessed from the LOSTFOCUS event of the key field.
Thank you! That did it.
I waited as long as possible before I did it, though, because I wanted to find that elusive error I thought must be lurking in the other handlers. And I dreaded getting into new problems. It's probably a good thing I did, because I found some dodgy code unrelated to the problem.
But finally I had to bite the dust and follow your advice. Except it's the READ handler that's the right place (after a Forward_Event READ), else the value is cleared by the READ.
And I took the opportunity to add some other handling to fix a weakness that's been giving me a guilty conscience for three years… So thank you again for throwing me in at the deep end.
- Oystein -
subroutine Skip_Control( Dummy )
declare function Get_Property
declare function Set_Property
declare subroutine Send_Event
/* Who has the focus? */
FocCtrlName=Get_Property( "SYSTEM", "FOCUS" )
/* Who is next in the tabbing order? */
NextCtrlName=Get_Property( FocCtrlName, "NEXT" )
/* Change focus to the next one */
OldVal=Set_Property( "SYSTEM", "FOCUS", NextCtrlName )
/* For some reason I also needed this.
At least I thought so back in the mists of time.
I've removed it now */
Send_Event( NextCtrlName, 'GOTFOCUS' )
return
At 23 APR 1998 08:34AM Don Bakke wrote:
Oystein
What's really wrong with the latter? Should they not be equivalent? In my app there are 27 user events and SPs with that syntax! Eeeek!
There is nothing "wrong", it's a feature. There are those times when you want GOTFOCUS event processing to be suppressed, and this is an easy way to implement that. See the PRG for the FOCUS property.