ScaleMode - Max Values

[GosforthPark]

I am writing a genealogy program and wish to design a family tree display. The display scrolls horizontally and vertically to display the generations of a family. The display is much wider than than it is high. I use a shape and labels to hold the individuals name and birth/death dates.
My first attempt had the scalemode set to twips but I discovered that when the left property of the shape/label exceeded 245745 then the value defaulted to 245745. Thinking that this might be a limiting value I changed the scale mode to millimeters and rewrote the procedures. Now the limit is 4334. which is ~ 245745/567 (567 is twips/mm). Obviously there is internal conversions going on which limits the maximum value of Left property.
Is there any way to exceed these values?

 

[Qik3Coder]

GosforthPark,

Usability question:
Do you seriously need to be able to see 16k pixels worth of data?

You may want to consider only showing a portion of the tree at any given point. In addition, you may want to consider having most of the tree near unreadable and as you hover or navigate through the tree certain portions change size to become readable.

HTH,
Lodlaiden

If [blue]you have problems[/blue], I want [green]source code[/green] AND [green]error messages[/green], none of this [red]"there was an error crap"[/red]

 

[GosforthPark]

I was trying to keep it simple.

The user builds the tree on screen and saves the positional and name/dob data to a text file.

Even with a small tree quite a lot of the tree would be outside the screen area and would come into view by scrolling.

The VB documentation states that the Left property of a Label is stored as a single-precision number in the units/scalemode of it's container. The highest resolution is in Twips and a single precision max value is 3.402823E38.

If you experiment in the design environment you find that the largest value the Left property will take is 2.45745e5 which is a lot less than expected from the documentation. All would be well if it lived up to its billing! Where does this limit come from?

 

[Qik3Coder]

Probably the datatype that the unit is stored in.
Visual Basic 5/6 came out in a time when a 15" monitor was the norm; what were you gonna do with 16k pixels?

Is there any reason that you cannot use an express version of VB.Net?
You will probably be able to get around some of the constraints that you have working with vb6.

The 2.4 looks like the maximum of a basic Integer (Int16[bit]).

I remember my grandfather working on an application like this when I was younger, It was almost ridiculous seeing the reemed paper 1/2 full the length wise and it was 10/15 sheets long.

If [blue]you have problems[/blue], I want [green]source code[/green] AND [green]error messages[/green], none of this [red]"there was an error crap"[/red]

 

[strongm]

>states that the Left property of a Label is stored as a single-precision number

Indeed. However this is merely so that it can cater for all the different scale modes rather than being indicative of the min and max values that it supports.

The values are converted "client coordinates" value (typically pixels for almost all output devices) and stored in 32 bit Ints as used by the underlying API calls - but the VB team for some reason known only to themselves decided to limit this to a signed 15bit integer during the conversion, hence giving a range of -16384 to 16383 pixels (or, as you have discovered, -245760 to 245745 twips, assuming the typical twips per pixel value of 15)

 

[GosforthPark]

Thank you Qik3Coder

I could be your 'grandfather'. I'm 70 now and I've been programming since the era of the Commodore PET. I program purely as a hobby these days and I'm converting my programs to VB.Net Express 2010. Slow progress, steep learning curve. However my genealogy program is a monster and most likely it will be the last one to do and VB.Net will prob be up to ver. 2020 by then!

Thank you strongm

That was the techy answer I was looking for. There's no work around so I'll have to take a different approach

Thanks everyone

 

[strongm]

>There's no work around

Well ... not entirely true, but the workaround would involve using the API directly