PDA

View Full Version : Reusing windowclasses possible?



ragamer
March 14th, 2010, 14:27
My problem is simple. I have a window layout I want to repeat multiple times in the same part of my sheet with slight alterations (in labels, etc).

As the behaviour of the window itself is heavily based on scripts I want to avoid having to declare multiple times similar window classes, on top of having to recreate the controls.

The way I want the windows arranged make it a bit hard to create a parent windolist and then consider each of the similar window as an item on the list.

So my "investigation" options are:

1) Use the prefered "windowclass template" approach, were I declare each window as a subwindow with the same windowclass and then try to "tweak" each instance. My 1st attempts have collided with the apparent impossibility to "transfer" custom fields from the parent window on each XML subwindow declaration so each instance of the class can be tweaked using the same code (things as labels and datasources, for example).

2) Repeat manually EACH windowclass definition altering slightly the controls and making ALL of them sharing the same scriptfile. Obviously a nightmare when tweaking "common" controls later as ALL changes need to be manually spread over the entire set.

3) Transform the concept of that part of the sheet from multiple disperse windows definitions to a single windowlist with each of the original window as a member of the list. This will mean that the physical possitions of each of the elements will be very restricted but it could be possible with a combination of noscroll and columns tags and some internal hardcoded size tables so each element can resize itself (Of course creation of new windows should be disabled at the top level). I have seen how 3E ruleset manages the skill sheet in multicolumn and they manage some nice effects... But before trying something similar, I want to be sure there is no other more "straight" approach.


Any experienced coder around that can share his/her experiences when dealing with the apparent impossibility to define true window templates?

Foen
March 14th, 2010, 15:15
I used a template based on the subwindow control to provide Rolemaster lookup-table functionality. It gets a bit mucky trying to link the hosting windowclass to the embedded windowclass, but it is doable. IIRC, the documentation doesn't give the correct information on how to link up and down the control chain, but it was a while back (so my memory may have failed me, and/or the documentation may have been fixed).

One of the problems you would face is the fact that subwindows don't instantiate synchronously, so you can't directly manipulate the subwindow content from the parent onInit event: you have to store the changes at the subwindow control level and then pass them to the inner windowclass using the onInstanceCreated event.

Foen

ragamer
March 14th, 2010, 15:32
Thanks for the lightning fast reply, Foen.

I read a lot about the OnInstanceCreated() event... And if I understood properly it's ankward. For example, if I create 3 windows using the same template then on the parent window XML something like the following should be used:



<subwindow>
...
<script>
function OnInstanceCreated()
[code for altering subwindow 1]
end
</script>
</subwindow>

<subwindow>
...
<script>
function OnInstanceCreated()
[code for altering subwindow 2]
end
</script>
</subwindow>

<subwindow>
...
<script>
function OnInstanceCreated()
[code for altering subwindow 3]
end
</script>
</subwindow>


ATM I'm probing option 3, converting the whole concept into a multicolumn window list... But it's going to be long so I would keep on monitorizing this for valuable tips... I wish I didn't had a timeline to fullfill :).

EDIT: After reading your post I stumbled into "onSubwindowInstantiated( )" event that allows you to trigger code ONLY if a windowclass is created as a subwindow control... Any experience on this? I will investigate this as Option 4 if 3 is not sastisfying enough.

Foen
March 14th, 2010, 15:47
I don't think I was very clear. I used templates to keep the code in one place:


<template name='mytemplate'>
<subwindow>
<class>inner_windowclass</class>
<activate/>
<script>
local innerwindow = nil;

function onInstanceCreated()
innerwindow = self.subwindow;
--[[ do stuff here, eg. innerwindow.someMethod(); ]]
end
</script>
</subwindow>
</template>

<windowclass name='inner_windowclass'>
<script>
function someMethod()
--[[ can be called from the subwindow onInstanceCreated function ]]
end
</script>
</windowclass>

<windowclass name='topwindow'>
<sheetdata>
<mytemplate name='subwindow1'>
</mytemplate>
<mytemplate name='subwindow2'>
</mytemplate>
<mytemplate name='subwindow3'>
</mytemplate>
</sheetdata>
</windowclass>


Hope that helps

Foen

ragamer
March 14th, 2010, 16:50
Your setup is comfortable as I can inject different tags defined into each template use through the method call as parameters.

Thanks for the clear example, helped a lot.

Foen
March 15th, 2010, 07:19
The thing to remember is that there are four contexts in which your code can run:

the top-level window class (topwindow in my example), which can access the template instances (subwindow1 to subwindow3) by name, as normal.
the template instances (subwindow1 to subwindow3 in my example) which can access the top-level window through the "window." mechanism, the template code through "super." and the contained window using "subwindow."
the template itself (mytemplate in the example) which can access the instances through "self." and the contained window using "self.subwindow."
the contained windowclass (inner_windowclass in the example) which cannot ordinarily access any of the outer contexts.

Because the contained window is unable to access the other contexts, I tend to add a registerParent() method to the contained window, which I call from onInstanceCreated in the template code, and pass it the value of "self". The contained window then stores that reference and can use it to access the other contexts.

Foen