They are strings because that's what we get from the command line (as
well as from the applet params). However, an application can convert
those arguments into any data type it needs.
On Jun 28, 2009, at 3:47 PM, Edgar Merino wrote:
Ok then, I won't mess with DesktopApplicationContext anymore,
although I
still think a more object oriented approach should be available to
get into
some properties of the windowedHostFrame, instead of passing them as
String
parameters, just a suggestion.
Edgar Merino
2009/6/28 Greg Brown <[email protected]>
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).
