5E Product Walkthrough Playlist
Page 2 of 2 First 12
  1. #11
    If you are going the windowlist route, I wouldn't even give the list a data source. Instead, use the createWindowWithClass API to instantiate the map image window; then close and open new one when swapping.

    Regards,
    JPG

  2. #12
    Using that to ensure a single element helps with the bounds issue, but windowlist has the wonderous behavior of adding extra padding such that the element within (the map) stretches height-wise more than it needs to due to some other esoteric properties.

    The solution to this is to modify the image control's static bounds to match the size of the windowlist (which is the entire window) to cut off this padding and keep the visible map in the application window bounds. I'll tinker more later, but that's the summation of what I discovered the night prior.

    The subwindow solution would help here, but there's also a re-size issue when the app-window is stretched as the windowlist is bounds 0 0 -1 -1. When the app window is resized, it doesn't fire the onSizeChanged from either the windowlist or the element within which is also scaling due to a similar bound span. I circumvented this non-resizing by hooking on to onHover and checking the container vs the element size and re-applying a matching static bounds to the image control within the singleton "map-list-element".

    In this most optimal case, I still loose 1 pixel on the bottom and right of the screen, I'm not sure if that's bounds 0 0 -1 -1 or the windowlist keeping that one pixel in reserve. I haven't bothered to figure out.
    Last edited by Ken L; October 11th, 2018 at 20:41.

  3. #13
    It works out well enough that it suits my needs. Given the relevance to this topic, I'll show a composite of what it looks like.

    It works dirty however, and I'm looking forward for the subwindow solution rather than this windowlist single element 'hack' I've got currently.



    The chat window, characterlist, and combat tracker are all panels rendered after the background map. The random magenta boxes in the upper left are placeholders for the map tool bar I'll be implementing eventually, but overall the concept works, a bit on shakey ground. I've yet to figure out how to make this work with connected clients but all in due time.

    You can also see that 1 pixel issue I noted earlier on the bottom and right. The windowlist is spanning the full <bounds>, but the element, despite the same bounds, refuses to fill out that last pixel. If mouse wheeled over that one pixel (and if the image window were larger as it was prior to my hack) it would 'scroll' this large map element as a giant list element (as opposed to the map pan).
    Last edited by Ken L; October 11th, 2018 at 22:15.

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Starfinder Playlist

Log in

Log in