Revisited my scrolling window of the ranges from my previous article and found some very strange results. Any display of data more than the window size would result in very odd scrolling results. I even tried a brand new form and still got erratic scrolling.
Looking back at previous scrolling windows I've done, some of the most solid results I've obtained were using "range where" conditions. I switched to that and the window is now rock solid.
I just cannot seem to master ranges and scrolling windows, except when using the "range where". So "range where" it is. You go with what works, right?
Monday, May 14, 2018
Friday, May 11, 2018
Dexterity ranges and scrolling windows
I have been doing quite a bit of Dex development and much of it centers around scrolling windows and the ranges that drive them.
I'm very thankful for David Musgrave's post in which he describes how to "future proof" your ranges. I immediately updated all my code to comply.
Now if you create a scrolling window there's a good change you're using a range behind it to drive the content. I'm going to explain a problem I had with this and how I solved it.
The table driving my range had a key that consisted of three filter values the user would provide on the form then click Redisplay. That worked fine with the three filter fields as the key but I noticed that the data displayed in the window was not sorted.
The only way I know how to sort data in a scrolling window is through the range that is driving it. And the only way I know how to control that is have the sort fields in the key used to fill the window.
(On a side note, I don't know if this is a real limitation, or just my lack of knowledge, but I have no idea how to do a reverse sort in a scrolling window.)
So here I am adding the sort fields to the key needed to present the data properly in the scrolling window. Acting on a major dose of ignorance regarding ranges and keys I placed the sort fields at the top of the key, instead of the bottom.
The scrolling window immediately lost control and presented nonsense results, basically it stopped responding to the filter fields in the form.
After going round-about this problem for an hour-plus, I decided that maybe having the filter fields come first in the key, followed by the sort fields might help resolve the issue.
And solve it that did! (Edit: or did it? See my next article.)
So if you need a key on your table that includes filter fields and sort fields place your filter fields first in the key and then your sort fields.
And by all means if you find a way to reverse the sort in a Dex scrolling window PLEASE SHARE!
Found it! Create a key with a Descending segment, and reverse the Clear/Fill options to create a Descending sort. I also found that Dexterity will not create the index with a DESC key. More work to be done there.
I'm very thankful for David Musgrave's post in which he describes how to "future proof" your ranges. I immediately updated all my code to comply.
Now if you create a scrolling window there's a good change you're using a range behind it to drive the content. I'm going to explain a problem I had with this and how I solved it.
The table driving my range had a key that consisted of three filter values the user would provide on the form then click Redisplay. That worked fine with the three filter fields as the key but I noticed that the data displayed in the window was not sorted.
The only way I know how to sort data in a scrolling window is through the range that is driving it. And the only way I know how to control that is have the sort fields in the key used to fill the window.
(On a side note, I don't know if this is a real limitation, or just my lack of knowledge, but I have no idea how to do a reverse sort in a scrolling window.)
So here I am adding the sort fields to the key needed to present the data properly in the scrolling window. Acting on a major dose of ignorance regarding ranges and keys I placed the sort fields at the top of the key, instead of the bottom.
The scrolling window immediately lost control and presented nonsense results, basically it stopped responding to the filter fields in the form.
After going round-about this problem for an hour-plus, I decided that maybe having the filter fields come first in the key, followed by the sort fields might help resolve the issue.
And solve it that did! (Edit: or did it? See my next article.)
So if you need a key on your table that includes filter fields and sort fields place your filter fields first in the key and then your sort fields.
Found it! Create a key with a Descending segment, and reverse the Clear/Fill options to create a Descending sort. I also found that Dexterity will not create the index with a DESC key. More work to be done there.
Subscribe to:
Comments (Atom)