Well I know its going to be like a ghost town here for a few days so Happy Thanks Giving and heres a quick question for after your Black Friday spending spree..

I have one of those wonderful scrolling dialog boxes where I display Contacts one after the other continuously all the way down, then the user can scroll up an down...

Question is is there a limit? as its stopped around 20 contacts and unable to scroll any further, and from the looks its possible its some how wrapping rest around row 1 again.

If there is no limit I guess it maybe my code, Not that I can spot anything right now...

Example Screen Shot


Have Fun!

Indeed, we're off momentarily to San Diego for the turkey ceremony, then Palm Springs tomorrow (hopefully beyond the reach of Black Friday, but then again, there might be some outlet malls out there.)

But to give you a quick answer, I did a little experiment here by modifying the DLGSCRL.BP sample program and did indeed find that it maxed out at 200 rows (like yours). 200...200..200? Does that ring any bells?

I don't have time to investigate it right now, but it sounds like the row/millirow threshhold (i.e. rows > 200 are assumed to really be millirows.) So maybe the trick is just to switch to millirows?

ah! OK...millirows (Hermans fault?)
I'll hang fire on this till you return...
Meanwhile, Enjoy

Can't believe you remember that, Steve!

You're never going to shake those millirows Herman. In fact, that may be your ticket to everlasting renown! (I hope when you're inducted into the Coordinate System Hall of Fame, you invite me to the party.)

But back to us working stiffs, after playing with this issue a bit more, I discovered that there was a bug that was exempting controls beyond millirow 40000 from being auto-replaced when a new control was added in the same position. This may or may not have affected you, but INFLD typically relies on this and it was causing some strange behavior in my test program DLGSCRL.BP - tabbing from the last field was jumping back to some seemingly random field in the middle rather than back to the first field.

That's fixed as of ATE/Windows 6.2.1422.0.

ash-6.2.1422.0-w32-upd.zip
ash-6.2.1422.0-w32c-upd.zip
ash62notes.txt

With that fix in place, you should be able to switch to millirows and create a scrolling dialog with many hundreds (thousands?) of rows. The updated test program allows you to input a number of rows to test, and I tried it with 1000 successfully.

If switching to millirows isn't practical, or you're trying to keep your code free of any Hermanesque features (Hermanisms?), then we have to figure out some other solution. One idea would be to allow you to specify the cutoff point between rows and millirows. But I would be surprised if that caused a number of unexpected results, particularly if you set the limit above 1000.

I may need Hermans help here as im a millirow noviced and after a first attempted it looks a bit of a mess..

This is what I get after following the millirow help
To convert erow to millirows, first add 1 and then multiply by 1000 (e.g. erow 5 is equivalent to millirow 6000).

Example After Millirows

Just by luck I had a function that displayed the field names and data using SXPINP so I thought i'll get away with just multiplying the row and col that came in, but I guess i've missed something obvious?

Hi Steve,

I would suggest ROW = (ROW*1000) + 100 to increase the gap between the fields.

Also check the misc settings for the vertical space here

Hope this can help.

Thanks Jorge, and just tried the following:
ROW = (ROW*1000) + 100
COL = (COL*1000) + 100

and ah... not much better.

New Example

Who on earth came up with millirows? :rolleyes:

PS. Playing and adjusting the "misc settings for the vertical space" only messed up all the other screens.

I took the day to mess up your screens :-)
What version of SBXINP are you using?

- My SBXINP.SBX is version 2.5(17)

It's a little hard to see what's going on in these pictures, other than everything overlapping. I think it would be more helpful to look at the control dump, ideally before and after, so we can confirm that the conversion is working.

Aside from that, here are a few suggestions about converting:

1) Millirows do not require millicolumns, so you can leave the columns alone, if you like. That might help reduce the chaos, at least initially.

2) INFLD only has the one row parameter, and since it is treated as a starting row, the formula would simply by ROWS*1000. (That's the only change I made to the DLGSCRL.BP example:
(Of course the example was extremely simple, with SBXINP being responsible for everything. In a "real" example you'll have to deal with start and end rows (where the complication is that for millirows, the end row value marks the bottom of the control and thus needs to be higher than the start row, even in a "single row" control).

3) As Jorge alludes to, leading (space between the rows) is critical here. When using standard rows, the system automatically makes room for leading. But when using millirows, the assumption is that you are trying to be precise, so the automatic adjustments are minimized. Thus, you may want to make your ending row be a few hundred millirows less. For example, in a control with srow=5 and erow=6, you might convert that to millirows 5000 and 6800 (rather than 5000 and 7000).

4) The control dump is helpful, but also potentially confusing, in that it always shows millirow values, but doesn't show the adjustments made for leading and other spacing options. (AUI takes note of whether you specified millirows or not, and uses that to make decisions about the final size of controls. Those adjustments are not shown in the control dump.)

5) The most common mistake in converting to millirows is just forgetting that the erow value refers to the bottom of that 'row', whereas the srow refers to the top. But that usually results in controls that are too short; your examples appear to have the opposite.

6) Beware B,1 and B,2 variables! (Millirows and especially millicolumns can easily exceed the storage limits of these variable types.)

7) As Jorge points out also, there are two other options on the Misc Settings dialog (allow edit boxes to use leading, and force edit box height to match combo) that will affect INFLD control height. However, I recommend you don't change them from whatever you were using before. Switching from rows to millirows should not interfere with your ability to get the exact spacing you had before. In fact, A-Shell internally converts everything to millirows, so clearly it is possible to get the desired result.

8) I recommend you create a function that converts rows to millirows, so you can tinker with the logic in one place. (One of the main problems with millirows is that it encourages micro-tinkering, which can easily result in a hodge-podge of different spacing.) Just remember that you need to tell it if you are converting an srow or erow value. Perhaps you want to have it handle either or both, using named parameters, maybe something like this:

Jack i've just emailed you an control dump, and an example using your Fn'Row'To'Millirow.

Looks like the main culprit is a B,2 variable holding the row value in one of your functions. The dump shows everything looking pretty good until we cross the 65000 millirow barrier and then it all starts wrapping, resulting in sets of fields being superimposed on each other (with 536 millirow offset).

Phew, I do believe its now working after changing the B,2 variables and also having to tweak my "Button Function" height variable etc.

Does this mean i've now passed the test (with everyones help I must add) and get a Millirow expert certificate? (or pen) ?

Congratulations! But I think you have to be a Millirow Journeyman for a few years before you get the certificate. And certainly before you get the pen!

I bet Herman has dozens of pens then....

Learn from Obi Wan Herman you must.

I do have the pen but it doesn't work...sort of like me

"doesn't work" is only relative to what the thing is supposed to do. The pen is only supposed to be coveted, so obviously it is still working. As for you... :rolleyes:

I'm really hurt

Wait a few minutes. Then you won't remember it. :p