True DBGrid Pro 8.0 (OLEDB) locks to .firstRow after switching to splits

True DBGrid Pro 8.0 (OLEDB) locks to .firstRow after switching to splits

Posted by: jk on 21 January 2018, 8:58 pm EST

• 

  jk

  • Post Options:
  • Link
    Copy
  • Jump To Answer

  Posted 21 January 2018, 8:58 pm EST

  After having switched to splits, we experience a random “deadlock” like condition where the bookmark points to one row, but the | cell-marker is on .firstRow.

  When the “deadlock” condition happens:

  • TDBgrid will return .firstRow instead of RowIndex in _FetchCellTips
  • .CellContaining(X, Y, RowNumber, ColNumber) will return return .firstRow too as RowNumber
  • .Bookmark returns .firstRow instead of the bookmark location
  • we can not move the | cell-marker with the arrow keys to a new row

  It has not been possible to replicate this “deadlock” condition in house on a constant basis, but it happens repeatedly to some of our customers and we have found other TrueDBGrid80 users with what seems to be the same problem:
  
  https://www.grapecity.com/en/forums/activex-edition/bug-in-firstrow-property
  
  http://computer-programming-forum.com/65-vb-controls/a5618a0d0db54255.htm

  Is there a known way to recover from this “deadlock” condition or avoid it all together? We are on the brink of having to roll back our software to the previous release, which our customers most likely won’t appreciate.

  We use ComponentOne True DBGrid Pro 8.0 (OLEDB)

  Kind regards, Martin.

• 

  jk

  • Post Options:
  • Link
    Copy

  Posted 22 January 2018, 1:34 am EST

  We have now also tried with the latest version of TDBGrid(8.0.20173.378) where the same problem occurs, but instead of the | cell-cursor locking to .firstRow, it can lock to any row in the grid, ie the immediate row before the bookmark or the very top row outside the visible grid area.

• 

  Pragati.Kaushik

  

  • Post Options:
  • Link
    Copy

  Posted 22 January 2018, 10:23 pm EST

  Hi,

  I could not replicate this issue at my end. Can you please share some code which demonstrates the problem at your end? I understand that the problem is sporadic, but it’s difficult to narrow it down without actually reproducing.

  f you can provide a stripped down project, it would also help in forwarding the problem to the development team.

  Thanks,
  
  Pragati

• 

  jk

  • Post Options:
  • Link
    Copy

  Posted 23 January 2018, 2:31 am EST

  Hi Pragati

  There is quite a bit of code, so it might take some time for me to get the relevant bits.

  But I can see that at every _RowColChange event, we do a rapidfire of .RefetchCol calls and the “deadlock” has a greater chance of happening at users who have the program called from a shared networkdrive, which is why we have had issues recreating the “deadlock” condition in our development environment. When the “deadlock” occurs, the bookmark will not change value, not even when we try to force a new value; .bookmark = 10.

  While I got you, when switching between splits, we experience that custom colours for column headers are only visible as long as a split is selected. Is there a way to force the unselected splits to also show our costum colours? I really want to switch to the lastest version of TDBgrid, but too many of our grids are dependent on header colours.

  Kind regards
  
  Martin

• 

  Pragati.Kaushik

  

  • Post Options:
  • Link
    Copy

  Posted 24 January 2018, 10:00 pm EST

  Hi Martin,

  1. Thank you for elaborating the scenario. Please note, it would be difficult for me to comment on the cause without actually replicating the problem at my end. Would request you to share a small application and I will try to call it from a shared network drive.

  2. I could not observe the behavior at my end. I used the product sample GENLEDGR (placed at: C:\Users\UserName\Documents\ComponentOne Samples\True DBGrid Pro 8.0\Samples\OLEDB\GENLEDGR folder) to replicate this scenario and changed the backcolors of the column headers of different splits at run time. I tried this using the column’s HeadBackColor property as follows:

  
  TDBGrid1.Splits(1).Columns(1).HeadBackColor=vbRed
  
  

  However, the color remains same even when the split 1 is unselected (or, the current active split is 2).

  Please let me know if there is anything that I am missing here.

  ~Pragati

• 

  jk

  • Post Options:
  • Link
    Copy

  Posted 24 January 2018, 10:36 pm EST

  Hi Pragati

  Inactive split header colouring:

  • Going through the grid properties and the online manual, I can see that the deselected splits lose their colours when the tdbGrid Appearance property is set to anything but 1 - 3D.
    
    http://help.grapecity.com/componentone/NetHelp/truedbgrid8/webframe.html#inactivebackcolorproperty.html
  • If using .apperance = 0 - flat, it is only possible to set the inactiveStyle on grid or split level, meaning we can’t show individual header colours on our flat grids.

  Bookmarak "deadlock:

  • For some odd reason, the length of the path name on the network-drive plays into the “deadlock” like condition. By changing to a long file path our older version of TDBgrid got more stable. The latest version of TDBGrid is more robust and works without the need of a long path name.
  • We will change our grid apperance properties to 3D, but I would be grateful if you could find a way to deactivate inactive colour change for flat grids.
• 

  Pragati.Kaushik

  

  • Post Options:
  • Link
    Copy

  Posted 29 January 2018, 8:53 pm EST

  Hi Martin,

  Thank you for sharing your findings.
  
  I am sorry but there is no other way. The inactive colors are only used when the grid’s Appearance property is set to 0 - Flat. If the Appearance property is set to the default value of 1 - 3D, then the headings do not change when a grid or split receives or loses focus.

  ~Pragati