Sign up on the Revelation Software website to have access to the most current content, and to be able to ask questions and get answers from the Revelation community

At 29 JUN 2005 07:40:17AM Tony Marler wrote:

It used to be 115 on 16 bit but is there a definative answer from RevSoft about the total number of controls allowed on a form for following 32 bit versions.

Version 4.1.3a

and

Version 7.1.1

Thanks, Tony.


At 29 JUN 2005 08:21AM Sean FitzSimons wrote:

Tony,

The maximum number of controls allowable on a form are 460 in both 4.1.3a and 7.1.1

Sean


At 01 JUL 2005 03:29AM Richard Guise wrote:

Although this may be the physical limit, with the normal ratio of data-linked controls, would a form with that many controls get a bit slow in practical terms?

If so, on typical kit, what would be an indicative practical limit for the number of data-linked controls before things get a bit sluggish?

When a multi-page screen is read, are the data items on all pages read initially or are they read page-by-page as the pages are used?


At 01 JUL 2005 10:06AM Tony Marler wrote:

Thanks Sean.


At 01 JUL 2005 11:04AM [url=http://www.sprezzatura.com]The Sprezzatura Group[/url] wrote:

Richard,

All controls are loaded in the READ event regardless of their visibility or position, so this *could* be a lengthy operation depending on the number of oconvs and post read processing you do.

Be aware that there *is* a finite amount of windows that you can have on a system, regardless of any OI limits or raw memory limits, this is why IE implements windowless controls for HTML imput elements rather than normal windowed controls.

A good dicussion on the topic can be found here. Incidentially I'd recommend reading this site on a regular basis - there's plenty of interesting information on why Windows works the way it does.

The Sprezzatura Group

World leaders in all things RevSoft


At 05 JUL 2005 09:19AM Richard Guise wrote:

Thanks for your helpful response.

In layman's terms your answer seems to be "suck it and see"!

Each of our records has rather a lot of editable fields and, as any user is only likely to be limited in a limited number of these at any one time, loading them all (incl the unwanted ones) would take quite a while.

Due to this, the earlier limit on prompts and the need to be able to produce variant fields/screens, we divide into "topics" each with a screen and a switcher which writes the record, fires the next selected screen and re-reads the record. With common screen layouts it's intuitive and it's quick.

Others must have similar situations and it would be interesting to hear what others do.

View this thread on the forum...

  • third_party_content/community/commentary/forums_nonworks/87ca92e3192b13578525702f00401cf3.txt
  • Last modified: 2023/12/28 07:39
  • by 127.0.0.1