LabVIEW
Allowing user to resize a Front Panel Control
Solved!
@Mancho00 wrote:
wiebe@CARYA wrote:
... So sizing, after a mouse down, to the maximum (for the user outside the panel) will result in a sticky drag, as the mouse up is not detected. You'll have to resort to polling, using the mouse API....
Actually, you just need to detect mouse leave for the panel.
Absolutely not.
As the user leaves the panel with the mouse down, he doesn't expect the action to be committed. Definitely not how anything in Windows works. Might as well accept the sticky mouse where the mouse up is ignored. You'd be using Beelzebub to cast out devils.
As an example, when pressing a Boolean it will latch when the mouse is released. Even if it's released outside the window. It would be very unintuitive and totally unexpected if that Boolean would latch when the user leaves the panel. Same for any scaling operation.
This is not far fetched or nitpicky. In this instance, let's say the string is on the top of the window, and has little height. So the user would grab the fake splitter, and starts moving. Changes are he moves upwards, outside the window. But then it will leave the panel, and the scale would a) discontinue as expected and b) be committed where the mouse left the panel. Very annoying behavior.
Search LabVIEW like a graph! 
@Mancho00 wrote:
wiebe@CARYA wrote:
@Mancho00 wrote:
wiebe@CARYA wrote:
... So sizing, after a mouse down, to the maximum (for the user outside the panel) will result in a sticky drag, as the mouse up is not detected. You'll have to resort to polling, using the mouse API....
Actually, you just need to detect mouse leave for the panel.
Absolutely not.
As the user leaves the panel with the mouse down, he doesn't expect the action to be committed. Definitely not how anything in Windows works. Might as well accept the sticky mouse where the mouse up is ignored. You'd be using Beelzebub to cast out devils.
As an example, when pressing a Boolean it will latch when the mouse is released. Even if it's released outside the window. It would be very unintuitive and totally unexpected if that Boolean would latch when the user leaves the panel. Same for any scaling operation.
This is not far fetched or nitpicky. In this instance, let's say the string is on the top of the window, and has little height. So the user would grab the fake splitter, and starts moving. Changes are he moves upwards, outside the window. But then it will leave the panel, and the scale would a) discontinue as expected and b) be committed where the mouse left the panel. Very annoying behavior.
I have to disagree. My expectations for boolean press behavior when leaving the panel are independent of scaling/positioning operations. I've seen many things happen when moving things around a panel, so I don't really have an absolute expectation of behavior. When leaving the panel, I've seen it be committed, or returned/rescaled to original position, or, just as you yourself expected, with its position maintained till the mouse returns to panel or mouse release.
Suit yourself. I don't except that in my applications. I like my customers happy 
.
Suit yourself. I don't except that in my applications. I like my customers happy
My customers would be happy to know that I'm not wasting a lot of time digging through APIs for what amounts to (for my applications) trivial UI optimizations. Of course, if this were an important part of an application, it may very well be worth the time.
@Mancho00 wrote:
Suit yourself. I don't except that in my applications. I like my customers happy
My customers would be happy to know that I'm not wasting a lot of time digging through APIs for what amounts to (for my applications) trivial UI optimizations. Of course, if this were an important part of an application, it may very well be worth the time.
You're right, my application leans heavy on the graphical user interface. But still, a splitter ain't to much work.
The problem with LabVIEW is that most of solutions do what you want 95% of the time. But they are also closed, so if you need something for the other 5%, it can be incredibly difficult. There are workarounds that almost work, but are difficult to get to 100%. Ironically, these issues are usually graphical...
In this case it is solvable, but some fiddling might be needed if the direct approach with a splitter doesn't work (for instance if a splitter can't be used because other controls are overlapping). A splitter in a VI in a subpanel might work. This splitter will work exactly like a regular one, but controls can overlap the subpanel. This does add communication from and to the VI in the subpanel. When done properly, this can be reused so it's a one time effort.
