Issue with positioning a popup menu with constrained body width

I am unable to position a popupmenu and have it stay fixed.

Function make_panel()
 
    NewPanel/W=(30,30,230,230)/N=Something/K=1 as "Inputs"
 
    PopupMenu popUpTest, fSize=12, title="Test", pos={10, 10}
    PopupMenu popUpTest, value="This;Something very long here just because it is long here", mode=1
    PopupMenu popUpTest, bodywidth=100
 
    return 0
end

It seems that the body width directive changes the pos={10,10} directive to become pos={0,10}.

What am I missing?

Igor Pro 9.06B01 (Build 56648) on macOS.

No, rather what happens is that a popup with the default size gets created at {10,10}, but then gets elongated to match the bodywidth of 100. This shifts the control to the left until it cannot move further. So it sticks to the left frame. What you are seeing is the control position after everything is done, which is more often than not different from the initial pos values, depending on how you modify the control. I would recommend to always use both the size and bodywidth keywords together and make sure they match:

Function make_panel()
 
    NewPanel/W=(30,30,230,230)/N=Something/K=1 as "Inputs"
 
    PopupMenu popUpTest, fSize=12, title="Test", pos={10, 10}, size={123,23}
    PopupMenu popUpTest, value="This;Something very long here just because it is long here", mode=1
    PopupMenu popUpTest, bodywidth=100
 
    return 0
end

 

I see. I expected the control position to be pinned to a bottom, left reference point and the size to be referenced relative to that pin point. This is the default for the absence of an align=... keyword. Specifically ... "If alignment=0 (default) ... and the left end position remains fixed if the control size is changed". Instead, the control is pinned (where???) , and the size grows (somehow???) if the bodywidth is something other than zero.

Interestingly, this approach does not have the problem.

Function make_panelx()
 
    NewPanel/W=(30,30,230,230)/N=Something/K=1 as "Inputs"
 
    PopupMenu popUpTest, fSize=12, title="Test", bodywidth=100
    PopupMenu popUpTest, value="This;Something very long here just because it is long here", mode=1
    DoUpdate
    PopupMenu popUpTest, pos={10,10}
 
    return 0
end

Commenting out the DoUpdate shows the issue. Forcing a repositioning of the control after it is displayed.

I will re-implement the control with the size={...} directive as well.

Perhaps a clarification is needed in the manual to explain when the bodywidth, size, and pos parameters may interact in odd cases that force the align=0 default to be essentially ignored.

Yeah, I agree that this is not so clear, especially when an external title is involved. Also note that you should have size and bodywidth together in case you change the control size afterwards (e.g., to accommodate a window resize). I basically just fiddle with the numbers until it looks good. I gave up on dialing this in in an intelligent way. But soon we will apparently be liberated from these issues when control guides are introduced.

Hopefully I've implemented control guides to do everything needed. We'll see during beta, I hope. It would, indeed, allow you to attach the left edge of your popupmenu to a guide. That would cause any changes in bodywidth or title length to cause the control to expand rightward. To align multiple popupmenu controls that all have the same bodywidth, you could attach the right edge to a guide. So far I haven't implemented a "bodywidth anchor" because I'm afraid of the complexity 😏

Until then, I would recommend setting a consistent bodyWidth, then align the right edge with something (another control, a drawing object?). Finally, get the recreation commands from the contextual menu for the control and use that in your code. The commands should include both bodyWidth, pos and size keywords that are all compatible.

The align keyword was my first attempt at making sense of laying out controls in a sane way when you have a bodyWidth setting. It was before I decided to tackle the complexity of control guides. It is a partial solution that I fear is hard to understand and use in a sane way.

Perhaps my use of LaTeX has me jaded or spoiled with regard to how I interpret anchor points and positioning for objects.

@chozo: I appreciate the advice. I take the same approach.

@John: If it is of any help, I have always appreciated reviewing the layout pictures associated with packages such as geometry https://www.ctan.org/pkg/geometry, fancyhdr https://www.ctan.org/pkg/fancyhdr, and memoir https://www.ctan.org/pkg/memoir to remind myself of what can and cannot be adjusted when trying to position fixed- or variable-sized objects (boxes) onto a fixed-size container in a defined layout. Perhaps the insights they provide in explaining what factor is doing what thing to what object can help you put your message forward in a clearer way. As always, please avoid adding complexity, especially when doing so is simply to satisfy the 1% of the crowd doing edge case designs.

Just to follow up, I drafted a picture of the actions of the various commands as I understand them relative to popup menus. This follows what is currently on page III-434 for value displays.

These kinds of pictorial layouts are worth ... dare I say ... a thousand words ... in expressing what settings do what where for the control.

Based on the pictures, I think is happening is that, absent the size={...} command, the centering point for the pos={...} is getting pushed to the (left, bottom) of the bounding box for the bodywidth frame, allowing the title to creep backwards.

My lesson from this is as follows: Set a size={width, ...} to at least cover the width of your title. This assures that your title is always anchored (left, ...) at all times. If you want to keep the selection text from extending too far, add a bodywidth command.

I think the challenge with control guides will be in assuring when the anchor position on the control stays in one consistent location -- the left, bottom (align = 0) or the right, bottom (align = 1) in all cases. As the behavior is now, I would say that the only clarification needed with the new feature in IP10 is to state categorically that the anchor position for the box that defines the entire content of a control will honor a fixed position of being to the furtherest left ONLY when the size={width ...} is specified. Otherwise, the control will appear to shift leftward in size in order to grow the title box as needed. No need from that point to include additional bodywidth anchor controls.

I hope my comments are taken in a spirit of being useful clarifications for improvements based on what I find is missing.

layouts for popup menus (263.29 KB)

JJ, thank you very much for the image. This is certainly very helpful. Yet, in my test I found that the examples where you specify bodywidth seem to work a little differently: The bodywidth parameter seems to always stretch the control from the right edge after the control has been placed at a certain position with a certain size (or the default size). You can also set this in action if you change only the bodywidth of an existing control. So, one needs to get the size right if aligning the left edge is desired. The correct size vs. bodywidth offset to end up at the initial position seems to also vary on certain conditions which I haven't quite figured out. One can of course play the DoUpdate trick to draw the control and then set the positions after the fact which however aligns the titles and not the control body.