How to programmatically click on a cell of an xBrowse?

[hua]

How to programmatically click on a cell of an xBrowse?

TIA

[nageswaragunupudi]

oBrw:SetPos( nRow, nCol )

nRow is the visible row number from top and nCol is the visible column from left.

[hua]

Thanks Rao. How to obtain the initial relative nRow and nCol?

Thanks again.

[hua]

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

Code: Select all  Expand view

     :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 lRet
 

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

[nageswaragunupudi]

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.

[Gale FORd]

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?

[James Bott]

Maybe you could gray-out the cells until the account code is entered.

Regards,
James

[hua]

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.

[James Bott]

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

[Gale FORd]

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.

[hua]

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.

[James Bott]

Gale,

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

[Gale FORd]

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.

[hua]

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.