How to programmatically click on a cell of an xBrowse?
TIA
FWH 11.08/FWH 19.12
BCC5.82/BCC7.3
xHarbour/Harbour
BCC5.82/BCC7.3
xHarbour/Harbour
Board index FiveWin for Harbour/xHarbour How to programmatically click on a cell of an xBrowse?
oBrw:SetPos( nRow, nCol )
nRow is the visible row number from top and nCol is the visible column from left.
Regards
G. N. Rao.
Hyderabad, India
G. N. Rao.
Hyderabad, India
Thanks Rao. How to obtain the initial relative nRow and nCol?
Thanks again.
FWH 11.08/FWH 19.12
BCC5.82/BCC7.3
xHarbour/Harbour
BCC5.82/BCC7.3
xHarbour/Harbour
Hi again Rao,
I'm trying to prevent user from being able to enter amount under Debit and Credit column if the account code is empty.
This is how I code it
So during testing I:
i. clicked on the cell under Debit
ii. pressed Enter and got a message that I'm not allowed to enter anything which is what's expected.
iii. pressed Enter again to close the message box. First problem, the previous cell in focus not reselected though oBrw:setPos() was called.
iv. pressed Enter again, expecting to get the message box again but instead I got the messsage "oCol:aEditListTxt not defined" which I don't know where it came from.
I did a screen cast to show what I mean and you can view it at http://www.screencast.com/t/h6X0rlLo
Any ideas are welcomed.
TIA
I'm trying to prevent user from being able to enter amount under Debit and Credit column if the account code is empty.
This is how I code it
:bEditWhen := {|oCol| CanEnterAmt(oCol) }
.
.
function CanEnterAmt(oCol)
local lRet := .t., nRow, nCol
if empty(oApp:oBrw:aArrayData[ oApp:oBrw:nArrayAt, LN_ACCN ])
lRet := .f.
// reset debit/credit amt col just in case
oApp:oBrw:aArrayData[ oApp:oBrw:nArrayAt, LN_AMOU_DR ] := 0.00
oApp:oBrw:aArrayData[ oApp:oBrw:nArrayAt, LN_AMOU_CR ] := 0.00
oApp:oBrw:drawSelect()
nRow := oApp:oBrw:nRowSel
nCol := oApp:oBrw:nColSel
msgalert("Amount can't be entered unless account code is specified")
oApp:oBrw:setPos(nRow, nCol)
oApp:oBrw:setFocus()
endif
return lRetSo during testing I:
i. clicked on the cell under Debit
ii. pressed Enter and got a message that I'm not allowed to enter anything which is what's expected.
iii. pressed Enter again to close the message box. First problem, the previous cell in focus not reselected though oBrw:setPos() was called.
iv. pressed Enter again, expecting to get the message box again but instead I got the messsage "oCol:aEditListTxt not defined" which I don't know where it came from.
I did a screen cast to show what I mean and you can view it at http://www.screencast.com/t/h6X0rlLo
Any ideas are welcomed.
TIA
FWH 11.08/FWH 19.12
BCC5.82/BCC7.3
xHarbour/Harbour
BCC5.82/BCC7.3
xHarbour/Harbour
bEditValid of a column in XBrowse may not contain any screen I/O like MsgInfo(), etc. This could result in unexpected behavior. We may have to accept this as a limitation.
Regards
G. N. Rao.
Hyderabad, India
G. N. Rao.
Hyderabad, India
That seems to be quite a limitation. I was going to use xBrowse for some data entry, but this might be an issue.
What would be your suggestion for informing the user what the entry error was?
Maybe you could gray-out the cells until the account code is entered.
Regards,
James
FWH 18.05/xHarbour 1.2.3/BCC7/Windows 10
Rao wrote:bEditValid of a column in XBrowse may not contain any screen I/O like MsgInfo(), etc.
I guess this applies to bEditWhen too?. I kinda agree with Gale it seems like a serious limitation. Hope Antonio could come up with some solution.
Thanks for the idea James. That's better than leaving a bewildered user pounding on the keyboard till it breaks not knowing what's wrong.
FWH 11.08/FWH 19.12
BCC5.82/BCC7.3
xHarbour/Harbour
BCC5.82/BCC7.3
xHarbour/Harbour
Here is another idea. Color the account code field pink until valid data has been entered, then turn white or green. Then un-gray the other fields, and if they are required then turn them pink until valid.
Regards,
James
FWH 18.05/xHarbour 1.2.3/BCC7/Windows 10
I don't think the user would know why it is invalid. I use valid routines all the time that take partially entered data and look it up in a database and present a list of choices. For instance a customer code. I don't think the user should have to know all of the 10 characters necessary to look up the customer code.
I would love to have a control that works like the Google toolbar field. Once you start typing it drops down a list and narrows the options the more you type the closer the match.
James Bott wrote:Here is another idea. Color the account code field pink until valid data has been entered, then turn white or green. Then un-gray the other fields, and if they are required then turn them pink until valid.
* sigh * When I was about to change the code I just realized this option is not viable for me as not all line must have an account code because users are allowed to key-in any additional remarks that they want. Well, back to the drawing board.
FWH 11.08/FWH 19.12
BCC5.82/BCC7.3
xHarbour/Harbour
BCC5.82/BCC7.3
xHarbour/Harbour
Gale,
I don't see why coloring the field precludes the use of your lookups. The color just shows that the field is required and invalid. Once valid data is in the field it turns a different color. It doesn't matter how the data got there. The field could also be a combobox.
Perhaps you could use a combobox for this. You could update the array with each keystroke.
A dbcombo with incremental search enabled works similarly except it doesn't eliminate the display of items beyond the matching items.
Regards,
James
I don't think the user would know why it is invalid. I use valid routines all the time that take partially entered data and look it up in a database and present a list of choices. For instance a customer code. I don't think the user should have to know all of the 10 characters necessary to look up the customer code.
I don't see why coloring the field precludes the use of your lookups. The color just shows that the field is required and invalid. Once valid data is in the field it turns a different color. It doesn't matter how the data got there. The field could also be a combobox.
I would love to have a control that works like the Google toolbar field. Once you start typing it drops down a list and narrows the options the more you type the closer the match.
Perhaps you could use a combobox for this. You could update the array with each keystroke.
A dbcombo with incremental search enabled works similarly except it doesn't eliminate the display of items beyond the matching items.
Regards,
James
FWH 18.05/xHarbour 1.2.3/BCC7/Windows 10
I thought the problem was doing something like msginfo() during the oCol get entry on xbrowse. I see it can be done with oCol:nEditType := EDIT_DATE because it does a drop down date selector.
I guess I need to do some testing and see what the limits are during the edit on xbrowwse.
nageswaragunupudi wrote:bEditValid of a column in XBrowse may not contain any screen I/O like MsgInfo(), etc. This could result in unexpected behavior. We may have to accept this as a limitation.
Antonio,
Can I know your opinion on this please? I got a bunch of bugs reported to me concerning my journal module that I redone using xBrowse and I just want to be sure which bugs are due to my fault and which part is because of limitation of xBrowse, if any. Thank you.
Of course, I'm still using FWH10.5 though.
FWH 11.08/FWH 19.12
BCC5.82/BCC7.3
xHarbour/Harbour
BCC5.82/BCC7.3
xHarbour/Harbour