itemfocuschanged vs. clicked

[Former Member]

I use a datawindow where one column is editable (checkbox). Now, I have the problem to find the right row when using the informations of this chosen column.

I tried this:

I created a computed field cf_row.

In my itemfocuschanged event I use the following code (it works fine):

f_set_current_row(this)

if row <> this.GetRow() then

    this.Object.cf_row = GetRow()

end if

// ***************************************************************************************

// * function     : f_set_current_row                                                    *

// * Beschreibung : aktuelle Zeile in Browser setzen                                     *

// * Übergabewert : adw_datawindow         Fensterobjekt                                 *

// * Rückgabewert : ll_currentrow                                                        *

// ***************************************************************************************

long         ll_currentrow

//change redraw to avoid flicker

adw_datawindow.setredraw(false)

ll_currentrow = adw_datawindow.GetRow()

adw_datawindow.SelectRow(0,False)

adw_datawindow.SelectRow(ll_currentrow,True)

adw_datawindow.setfocus()

adw_datawindow.setredraw(true)

return ll_currentrow

if I use the same code in the clicked event, it doesn`t work. So I tried "modify", but there is no success.

Where is the difference between the "row" in itemfocuschanged and "row" in the clicked event?

Any ideas?

Best regards

Martin

[Former Member · Accepted solution]

Hi Martin;

FYI: most of the DW Control events pass you the current "row" argument. You should not need to use the GetRow() method at all.

FWIW: you can replace the DW name by the pronoun THIS.  

Q: Where is the difference between the "row" in itemfocuschanged and "row" in the clicked event?

A: the Row argument on the ItemFocusChanged event is the row that the column (item) being operated on is associated with. The row in the clicked event is the row where the object receiving the click action is associated to.

HTH

Regards ... Chris

[ricardojasso]

Martin,

The problem is in the GetRow() method. When invoked inside the RowFocusItem event the method returns the current row as does the row argument of the event. When invoked inside the Clicked event it returns the last row that was current which is not the same as the row argument of the event (unless the user clicks on the current row). I don't know if this is a bug or if it is designed to work this way. Here is a screen shot of my modified test case:

Regards,

Ricardo

[ricardojasso]

Martin,

I build a test case to try to answer your question and found the following:

The ItemFocusChanged automatically fires when the datawindow control is created without any action from the user’s part. The row argument for this event is 1 and the datawindow CurrentRow() method returns 1.

Navigating through the editable controls on the datawindow using the Tab key fires the ItemFocusChanged where row and dwo hold the current item. The CurrentRow() method returns the same row as the row argument of this event.

Changing an item in an editable control triggers the ItemChanged event where row and dwo holds the item that was changed. If the control was modified by keying a new value and pressing the Tab key the ItemFocusChanged fires where row and dwo holds the item that has just gained focus but the ItemChanged event still has the row and dwo that was changed in the previous item.

If the focus is on an editable item and you click on another editable item with the mouse, wether it is a new row, a new column, or both, the ItemFocusChanged gets fired. If on the other hand you click on a non-editable control the ItemFocusChanged does not get fired even though the non-editable control changes its background giving the impression that is has just gained focus. The row and dwo arguments remain unchanged in this event. The Clicked event do gets fired with the row and dwo of the item being clicked on. The important thing here is that the CurrentRow() method returns the row of the item that retains the focus not the item that has just being clicked on. That’s because the item being clicked is non-editable.

Here is a screen shot of the test case:

I’m not sure this actually answers your question but I hope it sheds some light on the real answer.

Regards,

Ricardo

p.s. Your function f_set_current_row() doesn't actually sets a row to be current. What it does is that it gets the current row and highlights it after de-highlighting all rows using the SelectRow() method. Remember that the SelectRow() method doesn't change the current row. So, maybe a change in your function name is in place like f_select_current_row().

If this is so then the row argument in the ItemFocusChanged will be the same as the current row and if the current row is not changed in f_set_current_row() then the expression row <> this.GetRow() should never be true.

[Former Member]

The RowFocusChanged event is probably better for this. When it fires, you'll be on the new row and can use the CurrentRow argument to show which row is selected.

event RowFocusChanged(long CurrentRow)

if CurrentRow > 0 and CurrentRow <= this.rowcount() then
     this.SelectRow(0, False)
     this.SelectRow(CurrentRow, True)
end if

You may also want to consider just highlighting the row itself (this works per object too). Assign the following to the color of the detail band in the edit window, and get rid of any selectrow calls:

if(currentrow()=getrow(), 14737632, 536870912)

14737632 is a light gray, and 536870912 is transparent. By doing it this way, you get to control the color of the highlight yourself, and don't have to worry about the user's color scheme making the highlight so dark they can't see the text anymore. Use the RGB function to find a color value that works well in your system and replace the first number with it.

HTH,

Brad

[Former Member]

Hi Brad;

FWIW: While individual row highlighting is handled very well in the ItemFocusChanged event, this event does not lend itself to support the standard CTRL+Click or Shift+Click actions. Then you might also want the Select All and/or Unselect All menu or Pop-Menu support as well

   So if you want more standard MS-Windows mouse & keyboard behaviour, Martin is also going to have to venture into clicked and right mouse events as well.

Martin: I have this all done for you in my STD Integrated Foundation Class libraries for PB, Appeon Web & Appeon Mobile. Feel free to use the free open source framework or borrow my code from the "vs_dc_master" DW Control ancestor user object (or one of it's descendents).   

Regards ... Chris

[Former Member]

Thanks Brad,

this is not the solution I'm looking for at this point, but it's the solution for a customers wish laying on my desk since months

Thanks a lot

[Former Member]

Thanks Chris,

I feel like a newbie. The last years (I'm using Powerbuilder since Version 4) I never had the requirement to jump out of an editable data list to referencing detail windows

Thanks a lot

[Former Member]

Hi Martin;

I hope that this article might shed some more light on your question ..

Great White North Technical Evangelist: PB Event Order

Regards ... Chris