Notifications
Clear all

[Closed] A control for resizing controls

rollout testRoll "TEST"
(
	dotNetControl label01 "label" height:150
	dotNetControl split "label" height:7
	dotNetControl label02 "label" height:150
	
	local startPos
	
	ON testRoll OPEN DO
	(
		split.text =""
		split.BorderStyle = split.BorderStyle.FixedSingle
		split.backColor = split.backColor.darkgray
	)
	
	ON split MouseMove arg DO
	(
		local cursors = dotNetClass "System.Windows.Forms.Cursors"
		(dotNetClass "System.Windows.Forms.Cursor").current = cursors.sizeNS
		IF arg.button == arg.button.left DO
		(
			local theDiff = startPos-arg.y
			IF label01.height-theDiff > 20 AND label02.height+theDiff > 20 DO
			(
				label01.height -= theDiff
				split.pos -= [0,theDiff]
				label02.height += theDiff
				label02.pos -= [0,theDiff]
			)
		)
	)
	
	ON split mouseDown arg DO
	(
		startPos = arg.y
	)
)
createDialog testRoll

This snippet of code creates a rollout with a small .NET label that can be used to move/resize other controls on a rollout. It works like the splitContainer class in .NET, but this way it can be used outside a .net control, so it’s also effective for changing standard MXS controls.

I was wondering if anyone had a better/more efficient way of doing this. Any takers?

6 Replies
 PEN

Nice, I think that I would just use the split container. I have found that as soon as I start to try and get fancy with UI’s staying with Max only becomes limiting. dotNet is more work, but I find doing UI’s like that in max a pile of work as well.

Yhea you are right. This was one of those cases where things started pretty simple, so the old MXS rollout that smells like home seemed an ok solution. Then more stuff got added…then a bit more…then a tone more… and I needed some way of resizing and was to lazy to rewrite the whole rollout. =p

 PEN

Isn’t that always the case. The tool that I’m working on now I think I have restarted at least six times. Just ripped the guts out of parts of it again today for faster and better solutions.

This is using a Max script createDialog, two subRollouts and a whole pile of dotNet stuff. And it is using the splitContainer as well.

Ahaaa, looks like scripted fun!

Here’s my current GUI nightmare:

That’s TeaCup, a system for sharing materials and objects online I’ve been working on. The thing in the middle is a .NET flowlayout that holds a bunch of labels with the downloaded preview images. These of course are downloaded from an online database, so in order to keep the process from hanging 3d Studio I had to thread the whole process. Plus recently I’ve made it capable of caching the previews.
At the bottom there’s the info panel, that reports on the currently selected item in the flowlayout. Because of all the data that can be associated to a result item, I’ve split the info panel intro 3 parts, which means all the controls need to appear and disappear when the appropriate checkbutton is pressed (they are actually moving inside and outside the rollout btw).
And since the whole rollout is resizable, all of these controls have to move/resize accordingly. Which combined with the line for resizing the panels, plus the controls that move in and out makes for a real puzzle sometimes.

And I’m not even counting the whole “getting the database to work with MXS” shtick. Now, if only I could get someone to actually upload materials… :curious:

Hi Marco,

that’s a nice looking ui.
I’m working on something similar, just for materials. I hope to learn a bit from your work. My main window is a .NET listview. I was wondering: why did you choose to use a flowlayoutpanel? Does it work better with thumbnails than a listview? Or does it work better with the threading?
Secondly: could you tell us a little bit about the caching of the thumbnails? Does it increase the speed of displaying the thumbnails? And how do you store this cache: on disk, or is it recreated every session and sits in memory?

Klaas

The point of the flowlayout is that it automatically arranges the labels as you resize them, or the control itself. And adding and removing controls is somewhat easier. The threading has no real relation to it, you could thread whatever you wanted pretty easily I think.

Well yhea it makes it faster. It’s really nothing fancy right now: I have temp folder where I download the preview thumbnails, whenever a new search is started, the script checks if the next preview it needs to display is already on that folder. I should probably have some form of HD usage limit and have the script clean up the folder every now and then, but since the database is currently holding only about 60 materials, not much point for now.

BTW, the script can be downloaded and tested from: http://www.scriptspot.com/3ds-max/teacup