At the moment if you want to drag something like an inventory it has to be in its own window, which is not able to be embedded in the main game window. To get it embedded within the game window it has to be a pane. Doing this you lose the ability to drag it. This severely limits the types of interfaces you can make with BYOND when not using the webclient.
My request is being able to create a defined area inside of panes which they would be able to be dragged by. However, to go with this I'd like to be able to toggle whether the pane can be clamped into the screen region, or can ignore screen region boundaries.
ID:1948019
 Sep 23 2015, 4:16 pm (Edited on Dec 30 2015, 6:18 pm)
|
|||||||
| |||||||
|
Sep 23 2015, 4:45 pm
|
|
Inutaishos
 |
+1
|
So you're basically asking if a pane can be added as a regular control within a window, without being embedded in a child/tab control?
I think that makes some sense, though I'm not sure how it'd work. Maybe it'd make more sense to make the child control optionally draggable. | |
I guess that would work too. A toggle on child windows being draggable.
Would clamping the movement range to the viewport be feasible, though? | |
@Lummox:
DeferWindowPos() Would much rather do this with whole windows. Deferred positioning is a thing. Could probably be done with five new window skin parameters and then capture the move/resize messages. window.min-size //x,y pixel minimum size of the window window.max-size //x,y pixel maximum size of the window window.anchor-parent //id of the UI window to anchor this window to window.anchor-pos //x,y offset from the parent window's position. can be a number or percentage. Can also be negative. window.anchor-bounds //x1,y1,x2,y2 don't allow this window to be dragged outside of the bounding box. percents or numbers. It'd also be nice to be able to use disabled labels as resizer handles rather than only move handles. I've spent the last six months working on a UI library that makes resizable and draggable in-panel UI elements doable, but it's hacky and ugly. Bit of feature creep, but it'd be something to think about. | |
+1
| |
+2
| |
+1
| |
+5
| |
+3
| |
Bump
| |
Personally I think separate windows are the way to go here, it'd be cool to have a feature that prevents a window from going outside the default window tho.
| |
bump!
| |
Don't bump a post that has literally been bumped by someone two hours earlier. You already stated your support earlier in the thread.
| |
... bump.
| |
I'm doing it because nothing gets done, features and bug fixes requests for over 3+ years that still arnt address excuse my temper of bumping.
| |
Plenty gets done, there are priorities to be taken into consideration.
| |
I don't automatically implement whatever's at the top of the list. Some things get added and some don't. It's a question of need, ease of implementation, and priority.
Bumping can serve a valuable purpose for a buried request, when it's no longer on the first page, to bring it back to my attention. It serves no purpose at all when the post was already just bumped by another user. | |