We intentionally don't provide access to the frame, since, in general,
a Pivot application shouldn't need to be aware of the specific
application context in which it is running. Providing access to the
frame would be analogous to giving an application in a Windows VM
access to the VMware Workstation instance in which it is running. It's
just not a use case that the Pivot platform attempts to address.
That said, we don't preclude doing something like this. I think this
is a good example of when you might want to create your own concrete
subclass of ApplicationContext. That way, you are free to do whatever
you like with your containing frame.
Greg
On Jun 27, 2009, at 5:05 PM, Edgar Merino wrote:
I need to access the frame directly, along with some of its
properties, for
example I have one application where I had to made the frame
undecorated, so
I had to implement listeners to minimize/maximize/close the
application. For
this I needed to have access to the frame. Even if the
DesktopApplicationContext stays like it is right now, it would be
good to
have access to the frame directly (or think of a way to implement the
functionality described above).
Edgar Merino
2009/6/27 Greg Brown <[email protected]>
The main reason I modified the existing DesktopApplicationContext was
because I needed to set some properties on the HostFrame that were
not
possible with the current implementation.
Can you be more specific? What properties did you need access to?
I still haven't really thought on what I need to implement the wtkx
visualizer
You may want to consider creating a "WTK Visualizer" instead and
providing
an implementation for WTKXSerializer#writeObject() (or something
along those
lines).
