Good day -

I have a grid where the user can double click on a row to update the ins status. After this occurs i want to change the row color to show that is now updated.

Whats the best way to repopulate the grid with the new color with the least amt of thrashing? I tried 4 which will change the color but also seems to move the cursor and screen position. I am using NOREDRAW but i think there is another switch i am missing...

TIA

The double-click exit is probably not setting the XTR.TARGETROW to the selected row (since that is normally associated with cell editing validation exits), so in order to re-enter at the same row (using opcode 4, i.e. XTROP_RESELECT), you probably need to set the XTR.TARGETROW explicitly to the row in question. Also, to prevent it from adjusting the vertical scroll position, you'll want to activate the XTR.TOPINDEX feature (by initially setting it to -1).

I think TOPINDEX is what i was thinking about... let me look into that as well tx...

But basically the BEST was is: (in addition to making sure the re-entry row is correct)

Use OPCODE=4
NOREDRAW
TOPINDEX=-1

Update:

For some reason i can only get the row to update color with opcode=1. When i re-enter the grid it does keep the row position but changes the orientation on the screen (guessing doing some optimization, etc). Isnt there some way to suppress all of that?? Does opcode=1 ignore the noredraw logic? I guess it would assume if you are reselecting the grid and changing the data in the grid then it has the right to re-optimize the output. I guess this is a red herring then... i want to update the grid W/O changing WHERE the data is displayed. I think this is a reocurring issue with using xtree for data entry.

Unfortunately there are a lot of overlapping conditions at play in determining how much optimization/recalculation/redisplay goes on. Updating a row color doesn't sound like it absolutely requires disabling the NOREDRAW logic, at least in theory, but I'll have to dig into it to see how many triggers there are.

One possible workaround would be give up on changing the entire row color and instead changing the color on one ore more cells. In that case you could code them with coldef U (Application-editable only) and then definitely use XTROP_RESELECT.

Good point, thanks.

For what it's worth, I tried reproducing the issue in Steve's XTRA11 sample program. And there, changing the row color and re-entering with XTROP_REPLACE and XTF_NOREDRAW seems to work as you would expect.

If you want to try this, download the program and locate this section of code:

Insert the assignment as in the example above, which changes the row 7 bg color to "D" (greenish). To run, click on the Test Button Two, and watch it change color when you click OK. Activate the XTREE traces in the system message window to view/confirm that the XTF_NOREDRAW flag is being passed in, and the op = 1 (XTROP_REPLACE).

Good Friday Cap -

Same grid different problem.

This is a multi-level grid of only levels 0 and 1. The user can open a row to see detail, then decide to update that row before moving on. Lets say they do update that row it changes color to green - great. Now they navigate to the second parent row and open it, and again update that child row. When I re-enter the grid with opcode=1 to update the grid, it closes any row that was previously open. This negates the ability of the user to keep track of where they are in the grid if all "worked on" rows close. Is there any way to preserve the expanded status of rows when re-entering the grid? I do see XTEXPF_SAVE and _RESTORE but that reads to me like its saving the value of EXPANDLEVEL and not the individual row.

Confused yet???

Basically i want to reenter the same grid with opcode=1 w/o changing the expand/collapse of the rows.

No, not confused at all! It's actually a quite reasonable desire, and I think we've actually already handled it. The trick is finding it in the doc. I suggest starting at XTREE Techniques -> Multi Level Lists, where you should find something about the = format code which I think is the key. If that doesn't resolve it, I'll dig deeper.

Ok i did the above and added a "state" column with cformat values of "=U" for now am leaving H off so I can monitor.

Once I expand a row, edit and re-enter it comes back with the state="1" as expected. Now i update the second row, expand manually, edit, re-enter, and the first row which still shows "1" is no longer expanded! So it collapsed the row but is still showing "1" in the state column. Is there something else i need to do? Other than leave for the week and go find a cold grog somewhere??! So no rush...
TIA

Plan B sounds about right. I’ll have to dig around for a working example.

I created a new sample program XTRA29.BP which illustrates a multi-level editable tree with both both a cell-level and row-level color update on re-entry after a change (while preserving the expand/collapse level).

I think I led you astray on the expand/collapse preservation -- the trick is simply to set XTR.EXPANDLEVEL = XTEXPF_SAVE or XTEXPF_RESTORE. (The cformat = code is only needed if you want to test and/or modify the expand/collapse status in the application.)

As for updating the color, as I think you already determined, re-entry with XTROP_REPLACE will do the trick, regardless of XTF_NOREDRAW. You can also get it to update both row and cell colors with XTROP_RESELECT, which is probably more efficient (although I'm not sure if it will be noticeable due to optimization logic that avoids the redundant loading of unchanged data arrays), but you have to mark any columns that you want updated (including just color updates) with the U (application editable only) code. That because when re-entering using XTROP_RESELECT, it only updates editable cells. But in the case of U, the cell is only editable by the program, not the user. So the only advantage of a row color vs. cell color update is that in the former case, you have only one color byte to change for each row, whereas in the latter case, you'd need to update the color byte for each column.

Mornin Cap -

Thanks for working this out on your Sunday! (hopefully it kept you off the "honey-do" list at least ) The recipe above works in my code.

Followup question - i was using xtr.expandlevel to open the entire grid to level 2 if the user selected an option to expand all rows. How does that work with adding the save and restore option? Or does it eliminate that capability? At this point i would prefer the save/restore and force the user to open rows manually if necessary.

TIA

It was a nice break from bailing the proceeds from the latest 'atmospheric river' out of our house!

I'm not sure I understand the followup question. If you are combining an actual level (2) with the XTEXPF_SAVE and XTEXPF_RESTORE flags, on re-entry the will be ignored unless there is no previously saved status for this tree. (A prior call to the same tree with XTEXPF_SAVE will create a saved status, which will then override your explicit level if you continue to include the XTEXPF_RESTORE.)

So if you wanted to allow the application/user to override the saved expand/collapse level, you would have to remove the XTEXPF_RESTORE flag from that re-entry. Otherwise the previously saved status will take precedence.

If you also have a = (level status/override) column, then that would take precedence over the XTR.EXPANDLEVEL.

Ahhh Yes - its either drought or river out there Maybe you can build an underground tank to save all the extra precip for the next drought!

Ok let me reword the question:

How do i add the capability to expand ALL rows to level 2 while also using the save/restore option? Do i just add OR 2 to the end of the switch?

Yes, you can combine a level # (0-63) with the XTEXPF_SAVE and XTEXPF_RESTORE flags (which are 64 and 128).
But: since XTEXPF_RESTORE overrides any numeric level you set (provided there was a previous exit from the same XTREE with the XTEXPF_SAVE option set), you'd have to clear the XTEXPF_RESTORE flag in order to override it. In other words:

• To re-enter, preserving the previously saved expand/collapse status, use XTEXPF_SAVE + XTEXPF_RESTORE
• To re-enter, specifying your own uniform expand/collapse level, use # + XTEXPF_SAVE (omit the XTEXPF_RESTORE)

Finally got it sorted with some tinkering... its a bit of a chicken and egg game you need to play here! Thanks again.