Max number of controls on a form (OpenInsight 32-bit Specific) [Revelation On-Line Wiki]

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
[[https://www.revelation.com/|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]]


==== Max number of controls on a form (OpenInsight 32-bit Specific) ====
=== At 29 JUN 2005 07:40:17AM Tony Marler wrote: ===
 
{{tag>"OpenInsight 32-bit Specific"}}
 
<QUOTE>
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.
</QUOTE>
----

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

<QUOTE>Tony,



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



Sean

</QUOTE>

----

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

<QUOTE>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?

</QUOTE>

----

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

<QUOTE>Thanks Sean.

</QUOTE>

----

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

<QUOTE>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 [url=http://blogs.msdn.com/oldnewthing/search.aspx?q=Windowless+controls&p=1]here[/url].  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.



[url=http://www.sprezzatura.com]The Sprezzatura Group[/url]

[i]World leaders in all things RevSoft[/i]

[img]http://www.sprezzatura.com/zz.gif[/img]

</QUOTE>

----

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

<QUOTE>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.

</QUOTE>


[[https://www.revelation.com/revweb/oecgi4p.php/O4W_HANDOFF?DESTN=O4W_RUN_FORM&INQID=NONWORKS_READ&SUMMARY=1&KEY=87CA92E3192B13578525702F00401CF3|View this thread on the  forum...]]