The questionaire is dynamic in that respect, that depending on the
    answers the system may ask follow up questions, like in a decision
    tree. We want to insert the new questions in the right place, so we
    have to move all questions after the question that caused the follow
    up question 1 step down and insert the question in the free place. So
    assume that I have questions q1, q2, q3, q4 and want to insert q21
    after q2, you have to move q3 and q4.  Moving q3 or q4 obviously means
    that we have to move all widgets that represent the questions.

    Unfortunately moving a whole bunch of widgets may look, very, very
    funny in Common Graphics before the window finally is really updated.

Yes, I've noticed such visual weirdness, which is due to the fact
the widgets drawn in the new place before they are erased from the
old place.

    One can insert a couple of calls to update-window, to get a better
    looking widget movement, but that slows down the whole process. Our
    questionaires may consist of up to 150 questions with 5 to 10
    one/multiple choice alternatives per qustion, moving that is really
    slow, even on a fast 486.

I suppose that calling update-window on the dialog multiple times
would clear its background redundantly and thereby slow things down.

    An obvious improvement that we also implemented in Macintosh Common
    Lisp is to introduce subwindows for each question in the dialog . The
    widgets for the question may then be added to the subwindow, not to
    the main dialog.  Then moving a qustion only means moving the
    subwindow and not all individual widgets. Even the redisplay is
    acceptable, so this solution works fine in principle.

    But, the problem is that this solution does not scale up. Each
    subwindow seams to consume quite a lot of system resources. I don't
    know what system ressources are, but you can select help/info in the
    programm manager to see the amount of free system ressources.

As far as I know, various such things as windows, strings, and bitmaps
are kept in 3 or 4 "resource tables" that are global for all of the
Windows applications that are running.  These tables are arbitrarily
sized at 32K (or is it 64K?).  The number reported by program
manager is alledgedly the lowest percentage of all 3 or 4 tables.

    By experimentation I found that one can open about 100- 175 windows
    before your system ressources are zero and a call to open-dialog fails
    and returns nil.

    But more than 100 questions can easily occur in one questionaire, so
    it may happen (actually it happened with the knowledge base of our
    project partner)

It sounds as though widgets aren't consuming the resources as badly as
the parent windows are that you are putting them on, but I don't know
why this would be since widgets are windows themselves.  (Or are you
including widgets in your 100-175 number?)

One point to remember: be sure to not use bitmap-windows (and
bitmap-panes) unless you really need them since they consume a lot of
both resources and memory for their backing-store bitmaps.

Also be sure to call CLOSE on any windows no longer needed, so that
their resources are freed up.

    Is there any other way to group the widgets togehter. Are there
    perhaps ressorce free subwindows? May I increase the amount of memory
    used in the operation system for the resources?
    
Below is a technique that I came up with just now which avoids
redundant redisplay, avoids using extra windows, and erases the new
background area of the dialog before drawing the widgets in their new
places.  (I'm using a non-runtime function builder::shift-widget below
in place of whatever you use to change the dialog-item-box of each
widget.)

This technique is also faster than simply changing each widget's
dialog-item-box, but perhaps slower than moving fewer subwindows
with grouped widgets.

[This request has been assigned the tracking number pcspr1739.
For efficiency, please mention this number in the title of future
messages concerning it.  Also please cc: <franz.com at bugs> so that
someone else can handle your message if I am away.]

Ken Cheetham, Franz Inc.               1995 University Avenue, Suite 275
internet:  <franz.com at cheetham>          Berkeley, CA  94704
uucp:      ...uunet!franz!cheetham     voice: (510) 548-3600
"It's later than it's ever been!"      fax:   (510) 548-8253

---------------------------------------------------------------------------
;; set-value-fn of the button Button-1
(defun temp1 (widget new-value old-value)
   (let ((dialog (dialog-item-dialog widget))
         )
      (with-delayed-redraw (dialog)
         (dolist (j (dialog-items dialog))
            (bill::shift-widget j 20 20 t)))
      (invalidate-window dialog)
      (dolist (j (dialog-items dialog))
         (invalidate-window (dialog-item-window j)))
      )
   (values t ;; Accept the new value
      nil))  ;; Don't exit the dialog (if a pop-up)