Moving to a specific DataGrid row without using 'Selected Index:'


I have been trying to complete construction of a moderately sophisticated, keyboard driven DataGrid interface for an application intended to replace an old terminal-based application.

I keep thinking that conceptually everything is ok but … no matter what I try … I have been finding the mechanisms I put in place are unreliable.

In essence I have been trying to use knowledge of the current and previous DataGrid rows to determine if the active row needs to be automatically advanced to another row. If this is the case, then a tag configured within the DataGrid ‘Selected Index:’ field is adjusted to advance the DataGrid row.

Despite my best efforts, using a blocking tag to prevent repeat processing etc., I have not been able to construct a stable system. I suspect the cause may be due to using the ‘Selected Index:’ mechanism to specify the active row.

Can you please indicate if there is an alternative coding-based method to specify the active DataGrid row. I am sure this exists, but I have been unable to find a clear explanation of how this can be done. Coding for VB .NET would be appreciated … although I’m sure I will manage with C# :slight_smile:

Greg Shearer

Hi Greg,

We received your question and we are working on it.

Tatsoft Team.

Hi Greg,

What problem do you encounter when changing index in DataGrid and how are you changing the index? If you don’t want to use this property to do this:

Instead, try to use this code:

	Dim grd As TDataGridWindow = Me.CurrentDisplay.GetDataGrid("grd")
	grd.GridControl.DataGridObj.SelectedIndex = 5

Let us know if it helps you please.

Tatsoft Team.

Hi Eduardo.

My apologies for such a late response on this question … as I was on leave during last week … although still thinking about this problem.

The detail of the process is difficult to describe, as it is unusual for a graphical application. Unfortunately, using the method you suggested did not resolve the problem I am seeing.

As mentioned earlier, the process involves considering the data associated with the current datagrid row to determine whether to remain on that row or advance to the next row. There can be several sequential row advancements to skip over multiple rows which are inactive for various reasons, such as display of product characteristic data only.

So, at some stage the datagrid index is changed, with the expectation that a lagging change in the ‘Selected Values:’ data will then initiate consideration of the newly advanced row.

To me the process seems pretty straight forward … but as mentioned … I have been unable to construct a stable mechanism despite trying many different approaches.

I am wondering if the required ‘TwoWay’ binding I have in place can result in some instability in adjusting the datagrid index. That is, when trying to ‘set’ the datagrid index, is it possible that a background process can overwrite the attempted update? I ask this as the behavior I am seeing looks a bit like a ‘race’ or timing synchronisation condition preventing reliable programmatic control of the datagrid index.

I am continuing to investigate using debugging methods and will let you know if I can isolate the cause.

As part of my various attempts, I have tried using the tag ForceValue() function … although I am unclear of its correct application … without success. I have also tried using the datagrid ‘Pause:’ control … again being unsure of its intended usage … also without success. I have also put in place ‘blocking’ tags to control execution of code while possible conditional processing is taking place … also without success.

Overall, it appears that the datagrid index does not respond correctly to the type of programmatic control I am attempting to construct.

I believe I have solved the main issue I was having through some redesign and attention to passing a particular parameter ByVal.

I still have some other issues to resolve, but datagrid navigation is now stable and behaving correctly.

Hi Greg,

Thank you for reaching out to us. We wanted to ask if it would be possible for you to send us a video that shows the issue when it happens again. This will help us to better understand the problem and we can generate logs or maybe ask you for the project if it is possible.

Tatsoft Team.

Hi Eduardo.

I became frustrated with the method I was using and stopped working on this for a few months. I’ve recently started work on this project again and now have the interface working pefectly using a slightly different method.

The problem I think I had was that the 100ms DisplayIsOpen cycle could be faster than the processing I expected to be completed during each cycle. The impression I formed was that this allowed the row values and index to change while called functions were still being executed.

This description may not be technically correct … but it certainly accounted for the problems I was experiencing.

I now consider that issue resolved, and am progressing other coding elements.