last hail mary of codiing for interface extension....

[hagrid70]

well. ive finnished everything on this and its ready for release, or rather it would be except for one problem, that i have tried and failed to fix for the last month.
and one tiny query.

i need to increase the space between the bottom of each pop up window, and the point where FG draws in the textbox, and associated greeblies. this is a uniform problem across ALL windows, so i assume this is something in the core code, or in the windows code section. but i cannot locate it, and have failed to break anything that affects this placement.
thats the big bugbear, and im desperate for some help in this regard. the community and one or two people in particular have been supportive and generous with their replies in this regard, but ive still failed to locate the essential code. therefore: this area highlighted in purple is the key area. i need to increase this area by 10-20 pixels right across the whole interface.

the tiny query is about the placement of the resizing arrows, and whether the rollover for these is based on the arrow image or is set independantly.

my thanks to anyone interested enuf to read this, or kind enuf to reply.
i am happy to repay assistance with art if thats desirable.

[Ken L]

I'm not entirely sure what you're talking about. Every window is technically a popup window that's based on their 'windowclass' which defines how that particular window is displayed. In fact, you can make widgets that are 'windowclasses' which simply display an image that you can drag around. You have a great amount of control on how it appears unless you're referring to altering an existing window class.

In the beginning I used one of the core classes, but as I needed more control I started to use my own custom window classes. You can try copying the window class of this input window and name it something different, then make your interface spawn that window instead so you can edit it without worrying about breaking the 'base' window in the core package.

The resizing arrows themselves I believe is a frame definition (a nested definition). You can comment it out of the window class and they'll disappear entirely. You can instead copy that frame def (logically expand it you could say) and then paste it where the frame definition would be to edit the appearance of how the resize arrow appears to your liking.


Edit:
You can test your window's appearance easier by invoking the command /openwindow <windowclassnamehere> to spawn it immediately. However if you're relying on some kind of data node, or default data, the window won't have any of that information as it has no datapath binding that would normally be applied by reaching this window in a particular fashion (such as the NPC list window). It is however good for checking if your window's graphical placement is to your liking, and you can hot bar it rather than navigate the 'normal' path to open it.

[Nickademus]

The arrows are just a graphic. You don't actually need them. The area of the window that can be grabbed to resize it is set elsewhere.

I also don't understand exactly what problem you are experiencing. Can you make a mock up of a window that looks how you want it to?

[hagrid70]

cheers man. this i will take a stab at tomorrow. now i will be the first to admit im crap at code, as i think ive done above. but it LOOKS to me like all the text windows and butttons etc are written in on top of the popup, some distance up from the bottom of the frame. ive tried like mad to find a way to move this stuff up, and failed.
i will do a mashup.

[Nickademus]

I can probably tell you how to alter the window if I know what you are trying to do. It's most likely a margin somewhere.

[Moon Wizard]

Because of the way that window frames work, if you define a frame with different margin dimensions than the frame you are overriding (i.e. CoreRPG), you have to update every window class definition that uses those frames to add extra spacing at the bottom.

The easiest way to do this is to add a window class definition modification to your ruleset for each window that uses those frames.
<windowclass name="<windowclass>" merge="join">
<margins control="0,0,0,10" />
</windowclass>

Alternately, you can shrink the margins of the frame graphic so it's no longer an issue.

The long term solution is to add frame offset support for window classes, but this is not on our radar yet.

Regards,
JPG

[hagrid70]

this is a mockup of what i want to fix sir.20340

[hagrid70]

oops double post sorry

[Zacchaeus]

Alright Hagrid, maybe it's just my eyes but I can't see a difference between those two images :)

[hagrid70]

the offset between the bottom of the window, and the placement of the various widgets is different matey :D the previous responses in this thread beg another question: if i CAN move everything up the screen a little... will the rollover areas change as well. or will they all need to be altered as well? ( OH DEAR GOD WHAT A NIGHTMARE)

[hagrid70]

Moon Wizard: thank you sir. do i copy and paste this into the windows common file? do i need to copy paste this int0 every definition and replace the name "windowclass"?

[Ken L]

It's the Bottom spacer, I recall seeing spacers when I was modding the combat tracker, a similar concept is present here. I'd have to look at the npclist windowclass list to be certain.

[Moon Wizard]

Like I mentioned above. For every window class definition that uses the new frames you are defining, you would need to modify the window class definition to add a bottom control margin, similar to example.

It could be a lot of modifications, depending on how many frames you touched and how many windows are affected.

That's why I always suggest to theme creators to use the same graphical margins if at all possible.

Regards,
JPG

[hagrid70]

i nine-sliced every single window (cries like a neurotic)
thanks man for your time. gona have to battle this one out.