bb.donnay-software.com

From time to time - not reproducable -, I receive IDSCs from XbpBrowse:ForceStable, there in XbpCellGroup:DataArea:SetCell. The first argument of SetCell seems to be correct (a row number), the second is NIL in that situations. I do not use/overwrite those methods, but I do use ownerdrawing in browses intensively. The strange thing is that this happens in the same browse called x times before without any error. The error is raised by "oParent:Show()" from _DCGETBX.PRG (line 3188), but I do believe this is no error in eXpress++. It must be something else. It happens right after the dialog was build and is to be shown (resized, since there are statusbars).

I thought I was smart and rewrote XbpBrowse:ForceStable() in my own classes, embedding it in a sequence in order to catch the error - at least maybe showing one empty cell instead of having an IDSC. What I get is either an app freeze or a hang in XbpBrowse:ForceStable().

Does anybody know that situation? Any hints for corrections? I'm quite sure my ownerdrawing methods are correct, although they are very complex.

I thought I was smart and rewrote XbpBrowse:ForceStable() in my own classes, embedding it in a sequence in order to catch the error

Tom -

You may recall that eXpress++, at one time, had an overloaded :forceStable() to prevent errors and that turned out to not be a good idea, because then the programmers could not figure out why the browse was not displaying correctly.

Maybe a better idea would be to put some debugging in the XbpBrowse() source.

You can do this by adding XBP_BRW.PRG to the DCLIPX.DLL project file. It is already in the \exp19\source\dclipx folder.

Roger

Hi, Roger.

I do remember. There is still some code left from this in _DCXBROW.PRG.

I checked the browse source - thanks for the hint! - and found out that the error is raised by "BRW_ClearRow(<nRow>)", which is translated to "AEval(self:aColumns,{|o|o:DataArea:SetCell(<nRow>,NIL)})". This seems to be a mechanism to show empty lines in a browse that has less filled rows than rows to be shown. I'm going to investigate that tomorrow, since it's 11 pm in germany now. Thanks again!

Got it.

Thanks for the hints, Roger. I added some debugging code to my overloaded ForceStable method, in order to find out which parameters could be wrong when BRW_ClearRow(<nRow>) was called from the original method. Apparently, it worked with the same dialog, same table, same data about twenty to forty times and crashed then. Sometimes, it crashed with the first call. I checked the XbpBrowse source and found out that the lines beyond those containing data (table has 20 rows but only 17 are filled) are cleared there by setting a nil value to all cells. That forced the drawing routine to (re)paint those cells. In my own routines (CustomDrawCell), I checked some alignment parameters (retrieving the presentation parameters and others) and tried to evaluate the color settings before I checked if the cell to be shown was nil. In that situation, no ownerdrawing is done, but the method returns FALSE in order to hand back the drawing to the standard routines. But it was too late. I just had to check the cell value before this. But. The color settings and others already reflected the possibilitiy of having no/a nil value in the cell. That is the interesting point. And the fact that this only happened from time to time, but not always (with the same data, same background information, same colors and so on). However, it's gone now. Phew.

That's good news. I had a feeling that you would find out what was happening if you could dig into XbpBrowse() code.

Xbase++ 2.0 browse has been completely re-written.
I had made a minor change to the source once to support changing the scroll bar width and height, but realized this was a bad idea. I thought they may change the source, and this would have created problems for me. I found another way to do it and it still works with 2.0, so all is good.