Hi Mike;

   You make some great points! Please open a Support Ticket for this enhancement so that Appeon can get this into the queue- hopefully for PB2022.

  In the mean-time, I feel an STD Integrated Framework enhancement coming to a theater near you soon.   ;-)

Regards ... Chris

I wrote a grid service to address these things back in 2001.  It saves user changed grids for column order, size, and visibility.  It's on my anvil-of-time.com site if interested.  The best update to girds I can think of since then is the 'autosize width' feature put in in 12.5 or 12.6.  That eliminated a large chunk of code I had been using (I think originally taken from Roland Smith's website/examples).  My biggest complaint on grids is no control over the line properties and the highlighting.

...my .02

Hello Mike.

I also find myself in the same situation. I spend more time getting the GRIDs working than developing software that uses the same grids. I'd like to worry about other things and not making the grid data window work in a "modern" way. I understand that touching Xs in a grid is taboo. I realized that to make the odd and even colored lines I have to make them. I understand that I also have to manage to highlight the selected field in a datawindow. I understand that we developers can do it all by ourselves. I also realized that someone did something. The only thing I didn't understand is whether APPEON wants to make these blessed grids FULLY and REALLY modern or not. So, just to get an idea.
PS. Remember that to manage these implementations, it means that the performance of the datawindows slows down during the creation phase. Then if you have a single program with 20 datawindows ....

have a nice day and I hope someone reads these posts!

Another problem is that text objects in the header band don't always line up with their corresponding column controls in the detail band, making things look randomly inconsistent from column to column.

This may not work for your situation, but what I ended up doing to save the user's grid settings was to capture the size and positions of the text controls in the header band (they are named so that I can derive the columns that they belong with). I saved the values in the database, tied to the specific user and DW, but you could also use the registry. Next time the user opens the same grid, I create() the entire DW from scratch using template syntax in which I plug in the values of x and width for each control. As you noted, modify() doesn't work reliably.

I added code to move all the columns to the back first (columns get move past the last column in order from left to right), then move the columns to the front (first column gets moved in front of all columns).  So two loops that change the x value but going in different direction.

this seems to work (several reproducible examples now are fixed), and it is somewhat similar in concept to the visible technique.  Originally i just set first columns to front only, which worked about 95% of the time.  Then tried to only move the columns to the back, which maybe worked about 70%.  doing both of them seems to work 100%. 

This is probably faster than the visible technique.  At some point i may test with powerserver 2020 to see if it works there too (visible technique works in PB too but it has a bug that hides footer/trailer computes, PS2020 does not have that bug).

I cannot access my code right now, but we do something like this:

1. Store all of the column names and computed field names and its x and width values in the database.

2. When restoring, I put all of these stored values in a datastore which is sorted by x position

3. loop through all rows of the datastore and for each one, do a modify of the width and also of the x, but for the x value, I'm not using the value that's been stored. Instead I set it to a ridiculously high value, to make sure it'll appear as the most right column. Then go on to the second lowest x value on the datastore (second loop and second row). Do the same thing for all rows. In the end, all of the columns will end up being in the correct order. As you know, when assigning modifying to a very high x value, that will assure that the column will be most right, but it will always be positioned right after the previous column with grids. (so it wouldn't really end up having the "ridiculously high value").

If I'm not mistaken, you only have to modify the positions of what's in the detail band, the headers will automatically be adapted when they move.

After having looped through all of the columns, you might have to do a SetRedraw(True), but I'm not sure of that.

regards,

MiguelL

Hello,

Perhaps you can use this.

You could store dwo & dwsyntax per user in the db and use crete & Library import ONLY if your customers environment and your deployment & setup 

allows modifiying files per user on separate client pc.

lds_moddwo.dataobject = ls_objectname
dwsyntax = dw_data.GetItemString(ll_rader[ll_row],"dwsyntax")
if isnull(dwsyntax) then dwsyntax = ""
if len(trim(dwsyntax)) > 0 then
//test syntax with create
ll_ret = lds_moddwo.Create(dwsyntax, ls_errors)
if ll_ret > 0 then
//change sourcecode in pbd file according to customers needs

rtncode = LibraryImport(ls_pbl,ls_objectname, ImportDataWindow!, dwsyntax, ErrorBuffer )

if rtncode <> 1 then
//logg error
of_loggerror(ls_objectname,"En feil har oppstått." + string(rtncode) + " " + ErrorBuffer)
else
//change modified date on dwo, and syntax in db etc...
ls_dwostrtest = LibraryExport ( ls_pbl, ls_objectname, ExportDataWindow!)
ll_ret = dw_data.SetItem(ll_rader[ll_row], "modified",string(datetime(date(today()),now())))
end if
else

Regards

Brage

Mike,
Boils IMO down to storing/getting syntax in 3 main operations:
1. Always store syntax of dw in db in close event
dw_moddwo.Describe("DataWindow.Syntax")

2. Always use syntax of grid dwo  "as is" from your main source in events of change of user,version,PBD/DLL. 
You'll need a system/tables to manage this - always check on window.ClassName,dataobject,userid,version (of exe),date of PBD/DLL before applying syntax

3. If no changes according to step 2, always use stored dwsyntax from db if its there.
Get and apply syntax from db
ll_ret = dw_moddwo.Create(dwsyntax, ls_errors)

pbm_ithinkthiswillwork
Brage

the main issue for me is that the technique that i use (setting visible property on/off) ran into the old PB bug:  Track Bugs | Appeon

which has been fixed in 22R2.  Since PS and PB are the same runtime now, it finally works in both using the same technique.  

The nice thing with this approach is that if the datawindow is changed at all, the grid restore still works (in that the user's preferences are still set.)

It is still stupid that changing the x property doesn't actually move things around correctly, but the required functionality does work and it isn't too slow.