xBrowse buffer with Array

[TimStone]

A DBF file has selected data records written in an array.

The dialog upper section has two folders. 1) has GET fields for the individual elements of the array 2) has a totals screen

The lower section has an xBrowse of the same array It displays below the folders on the dialog.

As the xBrowse is scrolled, the selected row has it's data displayed in the upper GET fields
If I edit a Get field, above, it will change the value displayed in the xbrowse also.
If I scroll the xbrowse, all seems fine

When I change to folder 2, and then come back to folder 1, the value I modified reverts to the original value when the xbrowse was created.

It would appear the buffer for the array may differ from that used for the xbrowse, Is there a command I can issue which will take the edited GET value and make sure it updates the value stored in the xBrowse buffer ? I suspect there is, and I just don't remember it.

Thanks.

[nageswaragunupudi]

Must be programming error.
We can suggest correction if we see the source code

[TimStone]

It gets complicated ...

Creating the dialog with the folders and xbrowse:

Code: Select all  Expand view

    DEFINE DIALOG oSIdlg RESOURCE "STOCKINw" BRUSH oBrush transparent OF oWnd
        // Install two folders
    REDEFINE FOLDEREX oFldSI ID 800 OF oSIdlg PROMPT "&Stocking Items", "&Totals" DIALOGS "STOCKINaw", "STOCKINbw" ;
        ON CHANGE oLbx1:setfocus() ROUND 5 TRANSPARENT      // ON CHANGE

    // Create the browse
     REDEFINE  XBROWSE oLbx1 ;
       DATASOURCE oStkSrv:aStkPar ;
       HEADERS " Part ", " Description ", " Ordered ", " Received ", " Cost ", " Workorder ", " " ;
       COLUMNS 3, 8, 6, 14, 12, 10, " " ;
       ID 7802 OF oSIdlg ;
       ON CHANGE ( oFldSI:adialogs[1]:update( ), oLbx1:setfocus() ) UPDATE

    // Provide the header gradient
    oLbx1:bClrGrad := aPubGrad
    // Set the styles
    oLbx1:nMarqueeStyle := MARQSTYLE_HIGHLROW
    oLbx1:nColDividerStyle := LINESTYLE_RAISED
    oLbx1:nRowDividerStyle := LINESTYLE_RAISED
    oLbx1:nHeadStrAligns  := AL_CENTER
    oLbx1:nStretchCol := STRETCHCOL_LAST

 

This field is used to store the value that is modified. It is in the dialog on folder 1

Code: Select all  Expand view

    REDEFINE GET oStkSrv:aStkPar[oLbx1:nArrayAt,12] PICTURE "$99,999.9999" ID 823 OF oFldSI:aDialogs[1] ;
      MESSAGE "The actual cost paid per item" UPDATE
 

This is a "Save" button which actually refreshes the display of the xbrowse with the new value.

Code: Select all  Expand view

    DEFINE BUTTON OF oBarStk RESOURCE "HRSAVE" PROMPT "Save" TOOLTIP "Save part" ;
        ACTION ( oLbx1:update(), ::SumStock( ), oLbx1:setfocus( ) ) ;
        MESSAGE "Save the data for the highlighted part"
 

Here is why it is complicated:
oStkSrv is an object of the Purchase Order class
aStkPar is a DATA element of that class which contains the editable elements of the existing order. It is created from a DBF with just the records pertaining to the selected purchase order. After the editing is performed, then a separate method is used to save the array elements back to the database.
::SumStock is a method of the same class that simply multiplies the quantity received * the cost for a total. That total is stored in a memory variable.

A couple of other points.
oFldSI:aDialogs[1] contains the GET fields for the array elements
The oLbx1 xbrowse is attached to the Dialog, not the folders.

[nageswaragunupudi]

XBrowse and the Get object refer to the same array oStkSrv:aStkPar. This is an array being read and maintained by the class oStkSrv. If for some reason the class oStkSrv refreshes aStkPar from the dbf, the changes made by the Get to the array can be lost.

One suggestion is to use aStkParClone := AClone( oStkSrv:aStkPar ) in the XBrowse and for the Get. After all editing is done, then copy the contents of aStkParClone to oStkSrv:aStkPar and immediately save the changes to the DBF.

[TimStone]

Thank you for the suggestion. Once I thought about REFRESH(), I looked at what might cause it. I actually found a VALID process that had been recently added, and it was actually confirming data against the original DBF record in inventory ...

It's all resolved now.

Thank you.