Resizable Form Containing Multiple Scrollbars

[Minty23185Fresh]

For the Field Filters for All Libraries Extension, I would like to add a second scrollable control to the masterindex. I've been looking for a dialog or form that has more than one scrollable control or field and I can't seem to think of one.

The functionality I'm looking to parrot would be: on form resize, which control would resize first, by how much, and when does the second scrollable control resize. Or should they both resize simultaneously and proportionally?

EDIT: I guess another alternative is a "proportionality" control, you know one of those mid form controls, that you drag and it resizes the top portion and bottom portions of a form simultaneously, viewable area increasing at the top while decreasing at the bottom, or visa versa, while the form's total size remains the same.

I'm sure there must be such an animal out there in one of the rulesets, but I haven't located it yet. Thanks for the help.

[Bidmaron]

I only know PF, so I'm no help on other rulesets. If you have Savage Worlds, I've been impressed with the stuff he has done based on board discussions. However, I'd have to say that the odds of it not being in PF (and it isn't in PF unless there is an extension I haven't explored), or 5e or SW but it is somewhere else is really low.

I think you are doing this on your own, pal.

[Minty23185Fresh]

... I think you are doing this on your own, pal.

As Martin Crane said in a sitcom episode from the 80's, "That's pretty much what I figured."

And @Bidmaron: as an aside, my Field Filters.. extension now has been enhanced to specifically support the 3.5E/PF ruleset, instead of just inheriting minimal support from the CoreRPG.

Plus I can't wait for you to finish the "generators" extension you're working on. Since we're both slogging around in the masterindex, the chances of our extensions butting heads might be pretty high. Which, oddly enough is good, from my perspective. I am trying to flesh out a proposed methodology of mitigating extension collisions in the XML realm. I proposed this methodology a while ago as a means of mitigating inter-extension collisions in the "global scope" lua realm (a.k.a. "managers").

Moon Wizard said that due to layering of local script and its scope, a similar methodology for XML encapsulated lua might be difficult, if not impossible. Say something is impossible and I'm like a dog with a bone.

[Bidmaron]

Minty, I am using that methodology in what I am doing to the extent practical. I try not to completely substitute code. I am using layering on a windows basis. In some places, I have to wholesale swap out a control (although if I could ever understand the merge attributes well enough, I can probably eliminate that, but right now I keep getting warnings about anchors when I try to use merges on some controls).

I am so happy you added 3.5 and CoreRPG, but I am elbows-down butt-up trying to get 0.1 of Generators done (and I have all the way to 0.7 planned before 1.0) and tested, so I haven't had time to play with it yet. I have done some drag and drop stuff though.

Edit: I will be working on a control soon to do column resizing but no sub window resizing control.

[Moon Wizard]

You would have to define the scrollable region as a subwindow or windowlist along with a scrollbar, and embed all the subcontrols within.

The challenge is that you can't have two controls with unknown vertical dimensions trying to layout based on the height of the other one. One of them will need to be a fixed height, so that the other one can anchor to it and fill the remainder. The Groups dropdown in the master list window actually does something like this. It sets it's vertical height using setAnchoredHeight API function, and calculates that height based on the number of options available up to a maximum.

As for the splitter control, while I believe it may be possible using onDrag events, I'm not certain this is even possible or would work very well. You'd have to prototype it yourself to see if it can be done, and whether it works well enough to use. In reality, the splitter would just be a fixed anchor in between two scrollable controls (subwindow/windowlist) that you can potentially move around, thus resetting the fixed anchor position. However, you still need to deal with boundaries to keep people from moving side/side or too high or too low. I think the first option is much better.

Regards,
JPG

[Minty23185Fresh]

Thank you Moon Wizard. This is a lot to work through. I'll start wadding my way through it...

[Bidmaron]

Minty, I will be doing the horizontal equivalent in a few (I hope short) weeks, and I hope to get the draggable version working instead of the option MW is recommending. In my case, it is more important because if you are going to do resizable columns, it doesn't make sense to insist that one of them be statically sized. Plus if it is only one column static, it really doesn't help, as you would need all BUT one column to be static.

If you decide to tackle the draggable vertical resize, I will be watching.... I'm sure some of it will translate to what I need to do.

[Minty23185Fresh]

If you decide to tackle the draggable vertical resize, I will be watching.... I'm sure some of it will translate to what I need to do.

I wish I were that far along.. I'm a real noob when it come to the GUI. Almost everything I've done so far in FG had been functionality modifications based in the lua side. Once in a while a tiny cut-and-paste control addition. Slicing open masterindex and inserting a list control with all the support is beyond me at the moment. I have some learning to do.

[Bidmaron]

Well, maybe you can work something else until I get to the point where I'm working it. I am not a pro at the GUI either, but I have worked out a few things.

[Minty23185Fresh]

For the sake of completeness, follow this issue here.