Embedded browse anomaly/problem: How to navigate a browse via xbasic when there is only one child record and browse initially gets focus.....
The normal ways don't work via events until user navigates (manually) off browse record to a different browse record. (can't do this with only one record)
The following browse methods work fine with the "onRowChange" event, but not with onArrive:..... <browse>.left(), <browse>:<field>.activate() etc......
What I'm trying to avoid/accomplish is: I want to make sure that when the browse gets focus, the user has not selected one particular field. (Because the text in the field is color coded, and the focus on this row overrides the field's conditional text coloring while it has focus.) ~ Any suggestions on how to accomplish this?
Possibly a "hidden button" on these conditionally colored fields would work. But isn't there a more direct way using xbasic with the existing embedded browse events?
FWIW: The onArrive browse event will trigger normal commands like ui_beep() etc. so it should work, but it seems like the browse focus isn't fully resolved until you navigate off record. There's a "for i = 1 to x loop" that a5 uses to place the cursor via <browse>.home() and <browse>.right)() x number of times in the browse onArrive event. (watch script recorder/trace window) ~ And this navigational method (internally used by a5) appears to "inhibit" normal browse navigation via script when the browse initially gets focus. It actually could be an underlying cause of why the browse object events like onArrive are partially broken?
The only "navigational" capabilities (under this one specific circumstance) tied into the onArrive event (first item in browse) I've been able to find is via sys_send_keys() for example: sys_send_keys("{HOME}" I've tried many other things including ON_XBASIC_IDLE() and XBASIC_WAIT_FOR_IDLE() which have had some strange/unexpected consequences. For whatever reason, some of them (and other methods/functions placed within the OnArrive browse event) incorrectly trigger the onRowDoubleClick() event! ~ STRANGE!
The normal ways don't work via events until user navigates (manually) off browse record to a different browse record. (can't do this with only one record)
The following browse methods work fine with the "onRowChange" event, but not with onArrive:..... <browse>.left(), <browse>:<field>.activate() etc......
What I'm trying to avoid/accomplish is: I want to make sure that when the browse gets focus, the user has not selected one particular field. (Because the text in the field is color coded, and the focus on this row overrides the field's conditional text coloring while it has focus.) ~ Any suggestions on how to accomplish this?
Possibly a "hidden button" on these conditionally colored fields would work. But isn't there a more direct way using xbasic with the existing embedded browse events?
FWIW: The onArrive browse event will trigger normal commands like ui_beep() etc. so it should work, but it seems like the browse focus isn't fully resolved until you navigate off record. There's a "for i = 1 to x loop" that a5 uses to place the cursor via <browse>.home() and <browse>.right)() x number of times in the browse onArrive event. (watch script recorder/trace window) ~ And this navigational method (internally used by a5) appears to "inhibit" normal browse navigation via script when the browse initially gets focus. It actually could be an underlying cause of why the browse object events like onArrive are partially broken?
The only "navigational" capabilities (under this one specific circumstance) tied into the onArrive event (first item in browse) I've been able to find is via sys_send_keys() for example: sys_send_keys("{HOME}" I've tried many other things including ON_XBASIC_IDLE() and XBASIC_WAIT_FOR_IDLE() which have had some strange/unexpected consequences. For whatever reason, some of them (and other methods/functions placed within the OnArrive browse event) incorrectly trigger the onRowDoubleClick() event! ~ STRANGE!
Comment