Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: How to do multi-pane dialogs in IB?

On Tue, 19 Aug 2003 09:04:21 +0100, Jerry <email@hidden> wrote:

> We're trying to update old code so we can use Interface Builder but
> there's one big problem: we have many dialogs which have dynamic
> content in that they consist of multiple pages (like the System
> Preferences window). Using Constructor it's trivial to create one
> resource for each page and assemble them together at runtime. It seems
> to be impossible to do this with IB. We can't create one jumbo layout
> because the number of pages varies - they can be loaded from plugins
> for example. The only way I can think of is to create one window for
> each page, load it in, re-embed all the controls into the parent dialog
> and then throw away the window. The problem with this is that the docs
> say that controls can't be embedded from one window to another in OS 9,
> which we still need to support. Is there any way to do this with IB, or
> do we have to stick with Constructor?

The following might help:

*********
Date: Mon, 21 Apr 2003 15:46:19 +0400
Subject: BetterEmbedControl [Was: EmbedControl on existing control...]
From: Mike Kluev <email@hidden>
To: carbon-development <email@hidden>

On Tue, 01 Apr 2003 00:59:03 +0400 Mike Kluev <email@hidden> write:

> On 31/03/2003 22:05, Eric Schlegel <email@hidden> wrote:
>
> [about using EmbedControl across windows].
>>
>> Unfortunately, what you want to do will work on X (10.2 and later,
>> really), but won't (easily) work on 9. There isn't a supported way to
>> move controls from one window to another on 9.
>>
>> Having said that, it would probably be possible to include your own
>> definitions of the WindowRecord and ControlRecord structures on 9, and
>> manually transfer controls from one window to another by unlinking the
>> controls from one control list and linking them into the control list
>> of another window. You might also need to update internal data in the
>> controls (for example, an EditText control would need to have the
>> fields in the TERec that point at the owning grafport updated).
>
> I tried this really hard some time ago and concluded that this is
> very hard (if possible at all) to do. The problem is that while it
> is easy to unlink/relink control from nextControl list and it is
> easy to update controlOwner field appropriately and it is quite
> easy to update internal links to grafpots of those control that
> depend upon it (e.g. EditText), it is very hard to update internal
> links that form control hierarchy (parent/child relationship). The
> pointers that implement these links are not in the control record,
> nor they are nearby. These links are used thruout control manager
> (e.g. on ActivateControl or DrawControls calls). Maybe someone
> from inside who have access to sources can do it, but it is very
> hard to do it for someone from outside without sources.

It was hard but it was not impossible. With the help of reverse
engineering and couple of days in Macsbug I was able to create my
own implementation of EmbedControl that works across windows in Mac
OS 9. As a bonus I found the way to get the self (latent) visible
and active state of control and found the way to access other app's
windows/controls (only for Carbon apps).

The method (code name: BetterEmbedControl) was tested and worked
on 9.1, 9.2.1, 9.2.2, 8.6.

Potential problems:

1) Relies upon undocumented data structures.

2) Uses hackerish way to obtain the root "ProcessNodeHandle". Perhaps
there is a way to obtain it more directly (e.g. via low memory).
Currently I just grab it from the hard coded offset within the data
section of "ControlsLib" fragment. Not surprisingly, this offset is
different in 8.x and 9.x.

3) Due to (1) and (2) the method might break in future versions.
But wait, there won't be future versions of 9 :)

4) Some CDEFs store references to owner window/graf port. I fix this
reference for some known CDEFs. Unfortunately, under Mac OS 9 there
is no way to do it in general (there is no
kEventControlOwningWindowChanged on Mac OS 9): each CDEF that
stores references to window/graf port has to be tweaked individually.
Simple CDEFs (buttons, checkboxes, scrollbars, etc) do not store
references to window/graf ports, so they should not be tweaked.
Currently the following known CDEFs are tweaked: editText, listBox.

Sources along with the test program are available free.
e-mail me to get a copy.

Mike
_______________________________________________
carbon-development mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/carbon-development
Do not post admin requests to the list. They will be ignored.


Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.