Re: x_dialog Killfocus event
If you change the "^=" to "^+" then I believe they can key it in. The downside is that this method is an "edit list" instead of a simple "select list" it allows them to key in anything. If you really need to, you could probably get around that with some additional xbasic to trap anything that isn't in the list.
I haven't created code to do that but, since you would already have the list, I think the same KillFocus event could test to verify the result with a call to inlist2(). The trick is that the Tab info - the stuff between and including the braces - does not show up in the result. Therefore they have to be removed before making the comparison. This is just off the top of my head but I think it will work...
IF .not. inlist2( vSEGM, stritran_multi( test, "{T=20}"+crlf()+"{T=.4}", ""+crlf()+"" ) )
ui_msg_box(<Oops message!>)
ui_dlg_ctl_goto( agency + " Customer Information", "vSEGM" )
ELSE
<Normal stuff>
END IF
I put the stritran_multi() right in the IF statement because it only needed the two items and it runs a couple milliseconds faster by not having to set another variable first. If it was more complex I'd probably separate it out just so I could tell what I was doing when editing. It just needs to replace each {T=x.xx} combination with a blank.
BTW, I absolutely agree - keying things in is MUCH faster. I don't know why more people can't figure that out. I showed a couple people that using the keyboard was much faster than using the mouse and they basically said, "But I like using the mouse." So, now I just let them waste their time using the mouse because I know it's a waste of my time to try to get them to change.
Re: "We always seem to have to write around something that should work, but doesn't." Yep - BTDT. And this "can't key it in" issue is somewhat along the same lines. Why does one method always jump to the first item in the list for the last letter you typed while the other does a match to all the text you typed? Both methods should match what you type - the "exact match" method should just find the closest match and not allow you to type something that isn't in the list. Or make it an optional argument if, after doing a survey of the users, they found that some people want the jump to first item of last key typed.
If you change the "^=" to "^+" then I believe they can key it in. The downside is that this method is an "edit list" instead of a simple "select list" it allows them to key in anything. If you really need to, you could probably get around that with some additional xbasic to trap anything that isn't in the list.
I haven't created code to do that but, since you would already have the list, I think the same KillFocus event could test to verify the result with a call to inlist2(). The trick is that the Tab info - the stuff between and including the braces - does not show up in the result. Therefore they have to be removed before making the comparison. This is just off the top of my head but I think it will work...
IF .not. inlist2( vSEGM, stritran_multi( test, "{T=20}"+crlf()+"{T=.4}", ""+crlf()+"" ) )
ui_msg_box(<Oops message!>)
ui_dlg_ctl_goto( agency + " Customer Information", "vSEGM" )
ELSE
<Normal stuff>
END IF
I put the stritran_multi() right in the IF statement because it only needed the two items and it runs a couple milliseconds faster by not having to set another variable first. If it was more complex I'd probably separate it out just so I could tell what I was doing when editing. It just needs to replace each {T=x.xx} combination with a blank.
BTW, I absolutely agree - keying things in is MUCH faster. I don't know why more people can't figure that out. I showed a couple people that using the keyboard was much faster than using the mouse and they basically said, "But I like using the mouse." So, now I just let them waste their time using the mouse because I know it's a waste of my time to try to get them to change.
Re: "We always seem to have to write around something that should work, but doesn't." Yep - BTDT. And this "can't key it in" issue is somewhat along the same lines. Why does one method always jump to the first item in the list for the last letter you typed while the other does a match to all the text you typed? Both methods should match what you type - the "exact match" method should just find the closest match and not allow you to type something that isn't in the list. Or make it an optional argument if, after doing a survey of the users, they found that some people want the jump to first item of last key typed.
Comment