bb.donnay-software.com

I have a big DCBROWSE with 5 frozen columns on the left and 31-x (depending on the daycount of the month) non-frozen-columns on the right. Two of the five frozen columns on the left are optional; therefore, I create the browse WITH all five columns (the dialog is hidden) and delete those two optional columns using oBrowse:DelColumn. I show the dialog if this is finished (references to all columns are stored to an array). Before I created this system, I struggled around with creating browse columns on the fly, but this didn't work, since the DC_XbpColumn class has more iVars than standard XbpColumn (but I can't insert a DC_XbpColumn to a browse).

All the browse columns have unique identifiers in the CARGO slot, so I don't need to count how much optional columns are shown or not - in the datalink codeblock of DCBROWSE, I just look for the cargo[3] of the column (oBrowse:GetColumn(oBrowse:ColPos):cargo[3]) to identify the column.

So, now the user decides that he wants to see one of the optional columns or even both. I re-insert them at the right position (which works) using oBrowse:InsColumn(oStoredColumn). Everything fine? No.

Now, methods like oBrowse:GetColumn(oBrowse:ColPos):GetData() or :Cargo[3] return completely wrong results for the frozen columns. The display is still correct, but the column with former identifier "column1" now returns "column3" as :Cargo[3] and so on. If I look for the :GetData()-results, it's almost the same. As I said: The display is still correct, the browse dialog works besides this.

Is this a bug at :InsColumn() or am I doing something completely weird?

I do not know anything about your actual problem but it strikes me that you could instead just set those two columns that you do not want to show to zero width instead of removing them entirely...

Hi, Regan.

I already tried this idea, but it has two problems. If the option is off, the data-codeblocks of those columns become invalid, since the data inside those columns is not retrieved anymore if they are off. Okay, I could react inside the codeblock on this {||IF(!lColumnOptionIsSet,'',ColumnData())}. But the second problem is that keyboard-navigation still moves to those columns, which would lead to a hidden cursor. I would have to move the cursor one column further (which direction?) if this happens. Besides, a column with zero width still shows it's separators, which leads to a very ugly browse layout.

Tom

I think I recall having problems inserting a column when some columns are frozen.

I can help you figure this out if you can help me by writing the sample program.

Hi, Roger.

I will first check if this behaviour vanishes if I set oBrowse:SetLeftFrozen({})/oBrowse:Configure() before inserting the column and restore the frozen columns afterwards. If this doesn't help, I will try to create a sample. I already use this technique (SetFrozen/Configure) to force the browse to repaint correctly - I have a system which resizes all "daily" columns in this browse if one of the day columns is resized (so all "daily" columns always have the same width). After playing around with the sizes of the statics containing the browse portions, I found out that SetLeftFrozen/Configure forces the browse to repaint correctly, including the scrollbars.

BTW: The methods DCSetSize() a.s.o. seem to work great! Thanks a lot!

This did the job:

Great. Now I can get back to my fun project.