Some of the Wavemetrics panels do this already, even shuffling buttons. It shouldn't be too hard to look at the code for those panels an see what they do. I would like to know how to automatically specify column widths in listboxes so that users can scroll to see all the contents. Anyone got any ideas for that?

Some of the Wavemetrics panels do this already, even shuffling buttons. It shouldn't be too hard to look at the code for those panels an see what they do.

Yes, several of their procedures, including the Graph Browser, do this, but it's not very elegant (though maybe there's just not a better way to do this). I was hoping to think of a way to do this that would make it pretty easy to create a panel that resized gracefully, but haven't come up with a way yet. I don't know if other programming languages have built in routines that do this kind of thing automatically or not.

I've wondered about how to handle an equivalent problem of displacing control sizes/positions on the panels that I've been building. I've handled it directly in the Periodic Table Panel by fixing the panel as no resize and giving the user a manual popupmenu control input to resize it. Changing the magnification popup closes the panel and redraws it, rescaling the controls and resetting their placement across the panel.

Admitedly, it takes a bit of effort to code properly, and it is certainly not as elegant as having a smoothly resizable panel + controls. I've taken a step toward the latter problem by allowing the user to define their own magnfication steps for the panel resizing in a locallzation file.

Alternatively, I wonder (perhaps naively) whether the resize-panel hook event could hijack the kill-control eventCode for all control procedures to send size/position information to them in a dynamc manner?

I've wondered about how to handle an equivalent problem of displacing control sizes/positions on the panels that I've been building. I've handled it directly in the Periodic Table Panel by fixing the panel as no resize and giving the user a manual popupmenu control input to resize it. Changing the magnification popup closes the panel and redraws it, rescaling the controls and resetting their placement across the panel.

For your periodic table, this is a pretty good way of doing it, since you probably want all of the controls to grow/shrink. However, for panels with listboxes, the goal is usually to expand the list box but not the rest of the controls.

Alternatively, I wonder (perhaps naively) whether the resize-panel hook event could hijack the kill-control eventCode for all control procedures to send size/position information to them in a dynamc manner?

I don't see why you would want to hijack the kill-control eventCode. You can change the size of a control while it's alive and on the panel by doing something like:

NewPanel
GroupBox gb1
GroupBox gb1 frame=0

GroupBox gb1 size={100,50}

Maybe there's something you're trying to do that I'm missing.

Adam

Yes ... but I've had a different thought in the meantime. As the panel is being resized, can its new size be read dynamically within the window hook function? If so, then conceptually, it would seem that something like this would work ...


PanelHookFunction()

end


Since, as you point out, a control can be resized "live", the ResizeAllControls function would operate basically as ...

Function ResizeAllControls(rsf)
    variable rsf
 
    Button mybutton1, size={10*rsf,10*rsf}, pos={25+rsf*10,25+rsf*10}
    ListBox mylistbox1, size= ...
    ...
end

This could be expanded to use a (rsfx,rsfy) pair as inputs to the ResizeAllControls() function and have lower limits placed on both factors (so the controls do not "disappear" by becoming too small). Also, a STRUCTURE definition that sets the base sizes + positions for each control could be used to provide one place to define them for all functions that need them ...

STRUCTURE MyControlPanelSettings
 
    variable b1w
    variable b1h
    ....
ENDSTRUCTURE
 
Function InitMyControlPanelSettings(mCPS)
     STRUCT MyControlPanelSettings &mCPS
 
     mCPS.b1w = 10
     mCPS.b1h = 10
     ....
end
 
Function ResizeAllControls(rsfx,rsfy)
 
    STRUCT MyControlPanelSettings mCPS
    InitMyControlPanelSettings(mCPS)
 
    Button mybutton1, size={mCPS.b1w*rsfx,mCPS.b1h*rsfy}, pos ...
    ...
end

This initialization would be better done outside the resize and hook functions if possible (to speed things up), with the structure passed appropriately.

Would something like this work?

I think that if you go to Examples->Testing & Misc->Resize Panel and List Demo in Igor you'll see how to do resizing on-the-fly.

Also, a STRUCTURE definition that sets the base sizes + positions for each control could be used to provide one place to define them for all functions that need them ...

I've thought about doing this, but for most controls it would be more complicated, because not only do you need to have an "anchor" point to reference one corner (but not necessarily the upper left corner) to, but that anchor point can move as the panel size changes. Furthermore, some controls should not change size (for example, buttons) but some should (for example, list boxes). But you might not want the control to change size in both dimensions--for example, you might only want to allow a list box to expand up or down but not left/right.

It got to be so complicated that I just left it alone. But I might eventually come back to it. My plan was to store these parameters in the control's named userdata, which I've done for another project that makes fully functional tab controls very easy to create.

You might want to check out how this is done in the HDF5 Browser panel. Open "HDF5 Browser.ipf" and search for HDF5ResizeBrowser.

I've finally fixed this with http://www.igorexchange.com/cvs?commit=1039

Automatically closed -- issue fixed for two weeks with no activity.