Ok, so Sierra isn’t the problem. Interesting.
As for the sizing, it is completely manual. But you say that you can’t resize it? Here is how resizing is supposed to work, and does work on my computer. (BTW, this is with the release version, not the debug version that I usually use.)
Do you also get a beep when you press any key?
Hi Jim,
I get the beep when I press any key, including the enter or return keys.
Guido.
You know, actually, it wasn’t “designed” to do that, I just forgot to handle that situation. You are correct, it should save the changes, and I have made that change.
People wonder why programming takes so long – figuring out how to make this one little change, which you might think would take 5 minutes, took several hours. It was really difficult to figure out how Apple’s code could notify my code that the window was closing due to a click outside the choice palette. But I finally figured it out.
And next time, it will take 5 minutes. 
Robert Ameeti
Jim:
Thanks for the quick reply. When I go to the corner of the box, it does resize. I would expect the side and bottom resize tools to work as well, and they don’t do so consistently (but they do show up, giving the impression that they should work).
…somewhat later…Ok—I just noticed the very subtle white dots I have to hit with the mouse. I didn’t notice those earlier because my system gives the resize tools (horizontal or vertical arrow) when the mouse is just a couple of pixels away. When I click on the dots, it works fine. Sorry I missed that, but if there’s a way to use the tools, that might be less confusing to others.
I do also get the beeps with any key, and the value doesn’t change, even if I change it in the box. That may be because I am also dismissing the box by clicking outside.
Good luck…
Rich
Ditto here on Gary’s example. 10.12.1
Actually it is the Tab key that does nothing not the Escape key.[quote=“rblatchly, post:19, topic:763”]
Ok—I just noticed the very subtle white dots I have to hit with the mouse. I didn’t notice those earlier because my system gives the resize tools (horizontal or vertical arrow) when the mouse is just a couple of pixels away.
[/quote]
Funny, I never even noticed those dots around the edit boxes. On my screen they are almost unnoticeable as shown in this enlarged screen shot:
Might be a good idea to make them more visible so the user is automatically aware they exist.
I see Jim’s moving example of how to resize the CHOICE PALETTE. I’m glad it works for him, but it doesn’t work for me. I try clicking in all the obvious places, and get the “X” symbol, but it doesn’t do anything. Repeated trying sometimes lets me expand the palette to the right, horizontally, but I can’t get it to resize vertically, which it what I need. When it rarely resizes horizontally, there is no vertical movement at all. I have OSX 10.12.3.
These resizing targets are pretty touchy and sometimes hard to trigger as desired. The vertical control seems to be the most sensitive and I have found that it actually responds better when you are on the far left side of the lower shadow where there are no apparent trigger points at all. The diagonal adjustment is best triggered when clicked in the extreme lower right corner (as close to the tip of the shadow corner as possible while still displaying the “X” cursor) and held for a second before adjusting. If all else fails you can force an adjustment with a couple of lines of procedure code:
field MyChoiceField
setfieldproperties initializedictionary("EDITWINDOWHEIGHT","500")
This will increase the popup choice box to 5 lines in height (100 for each desired line height).
It’s not necessary to click on the dots – anywhere in the translucent edge on the bottom or right will work.
Gary mentioned that you can use a procedure to adjust the height, and you can also use the Field Blueprints dialog.
Though this shouldn’t be necessary, you should always be able to adjust by dragging the edges.
My experience is that in 10.12.3 the center height adjustment is pretty no operative and only the far left and far right portions of the lower shadow are seem operable as shown below.
Ok, got it. Notice in my movie that the window is never shorter than the radio buttons. But if I do make it shorter, then the problem appears, as shown in your movie. The radio button is interfering with the resize area. In fact, if you click in that area, it activates the radio button instead of the resize option. That’s why it works in the far left, you are clicking outside the area of the radio button.
I’ve added this to the issue tracker.
FYI I’ve fixed this bug, and also found a bug in how Panorama decides to show the cursor as a resize arrow instead of as a regular arrow. Bottom line, resizing the Input Window will now be much easier in all situations, not just when radio buttons are used. As a bonus, when choices are set up, Panorama X now automatically sets up the height of the Input Window – in other words, if there are 5 radio buttons, the height is automatically set to the proper height for the buttons.
Hi Jim,
Would it be possible to display the choices palette as multiple columns when resizing the window wider and less tall? That would make a long list of choices in the choice palette much more usable.
Guido.
The choice palette IMHO should have a scrollbar if the AutoChoice button has created a lot of choices (e.g. more than a window’s height).
And, please, Jim, Choices should have an option for exceptions again (like in Pan 6). If I understand it correctly, at the moment you can’t enter exceptions when the field is set up as Choices Palette, or can you?
I apologise for reviving a thread from nearly six years ago, but, although I had briefly played with Panorama 6 before then, I hadn’t yet discovered and started to use the infinitely superior Panorama X at that time.
Jim rightly makes much of Panorama X’s modern, Cocoa-compliant user interface, and yet this so-called ‘choices palette’ produced when clicking a data sheet field of type ‘Choices’ is a notable exception: a fairly crude pseudo-menu with a thick translucent border, extending vertically downwards from the data cell concerned to the bottom of the display if necessary. As Kurt noted, and also Guido Arnout in another thread, there is no way to select items that might be lost if this vertical space is not large enough to display the whole list of choices; if the data sheet extends to the very bottom of the display and a choices field in the last record is clicked on, only the first two choices are displayed. The ‘choices palette’ includes radio buttons down the left-hand side. Since its width is the same as that of the data sheet column for that field, unless the display width of that column is somewhat wider than the widest of the choices, at least some of them will be cropped in the ‘choices palette’ even if they are not in the data sheet itself. Similarly, if the data sheet column for the field concerned is only partly visible at the right-hand edge of the display, the ‘choices palette’ too will overflow the edge of the display.
All this makes it very frustrating to use the ‘Choices’ data type.
I would have expected Panorama X to use a standard Cocoa popup menu in this situation, which would automatically:
pop up from the bottom of the display when activated near it, and scroll whenever there are too many entries to fit vertically on the display;
be wide enough, and positioned appropriately in the X-axis, to accommodate the widest entry, regardless of the display width of the data sheet column and the position of the column concerned on the display;
disappear when a choice is selected, and display that choice in the relevant record/field cell of the data sheet.
The strange thing is that there is already a command to produce exactly such a menu, albeit one whose list of choices is derived from the existing contents of that field in all records, rather than from the pre-specified list, not all of whose options might currently exist in that field of the database:
popopfieldchoices choice, field, initial
If someone were to create a form to replicate the data sheet exactly in every other respect, something along these lines could be used to launch a submenu when a cell in a field of type ‘Choices’ is clicked. Not this exact command, however, because:
grabfieldtype( returns zero (type ‘Text’) for a field of type ‘Choices’, thus it might not be possible for the user to distinguish between those two field types in the first place;
the field parameter requires a fixed field name rather than a string or integer to identify it, thus it couldn’t be used dynamically for any arbitrary field;
there doesn’t seem to be a documented way for the user to access a string array of the choices available for a ‘Choices’ field (which I assume are stored internally as integer indices to a string array), only to compile a duplicate-free array of the string values currently used.
I for one wouldn’t want to create such a pseudo-data sheet myself anyway, but is there any chance, please, that the current ‘choices palette’ in the data sheet could be replaced by a more user-friendly and standard scrolling popup menu, containing all the pre-specified choices, with the current contents of the field highlighted, and displayed in full regardless of its length or width, or from which position on the screen it is activated?
It’s possible now to make a popup menu appear when you click on a data sheet field. The help page you want to look at is Automatic Field Code.
Further down on this page it shows how to use the popupclick statement to make a popup menu appear. The example uses a hard coded list of items, but you could use the getfieldproperties( function to automatically get the list from the list of choices:
getdictionaryvalue(getfieldproperties(),"CHOICES")
So the complete code you would need would be something like this:
return
click:
local choice
let choices= getdictionaryvalue(getfieldproperties(),"CHOICES")
popupclick choices,"",choice
if choice<>""
«»=choice
endif
I didn’t expect such a quick reply to this when you’ve got so much else on your plate! Thank you.
That’s interesting and very helpful. I had missed the click: label.
The code above works for me except that getdictionaryvalue(getfieldproperties(),"CHOICES") returns a space-separated array such as is displayed in the Choices box of the Field Properties panel, whereas popupclick and similar commands require a CR-separated array. Thus I changed that line to:
let choices= replace(getdictionaryvalue(getfieldproperties(),"CHOICES")," ",cr())
I’m not sure it’s exactly the answer to the problem, however, because:
In other circumstances, a single-click is used to select a record/field and a double-click (or tab key) is used to modify it. Single-clicking a Choices field when the intention was merely to select it, not to modify it, could easily result in unintentional selection of a spurious item if the next click is over an item of the resulting menu (especially easy if it’s the second click of a double-click and the first item of the menu is adjacent to the mouse pointer).
Sometimes (but not often — I can’t work out exactly what triggers it) a double-click in that situation still activates the choices palette too, behind the popup menu.
If the data sheet window is not fully populated horizontally (by field columns) and/or vertically (by records), a click in the empty area to the right of the last field or below the last record can activate the click: code, just as a double-click in that area would open the leftmost field (for some reason) in the double-clicked record for editing. But the latter would probably be a deliberate action, whereas a single click in that dead area is more likely to be intended just to select the record, not to modify anything. Either clicking or double-clicking in the area below the last record would usually only select the field in whose column the click lies, in the currently selected record. But using this click: code, if the click falls within the x-co-ordinates of that field’s column, not only is that field selected in the currently selected record, but of course the menu opens to modify it, which was probably not the intention given that the user had not clicked a specific field/record cell. And if a cell is already selected in the column of the Choices field, a click anywhere in the dead area to the right of and below the populated cells will cause the popup to open to modify the selected field/record combination.
If the data sheet is not the active window, a click that would invoke the click: code if it were active sometimes produces a single-item empty menu, which is harmless. But more often, instead of activating the window, it invokes the click: code, producing a menu and potentially causing a spurious data change in a situation which is even less likely to be intentional.
(The help page states: ‘Starting with Panorama X 10.1, you can add a special click: label to the code and specify actions that will run immediately when a field is clicked in the Data Sheet. Here is an example that overrides what happens when you click on the Use field in this database.’ However, the above suggests that the click: code doesn’t override the usual effect of the mouse click but occurs after it.)
Maybe a separate doubleclick: label would be the solution, invoked only by a double-click, and only when the co-ordinates of that click on the data sheet fall under a valid field/record cel. Thus it wouldn’t interfere with the usual single-click operations. It would need to override the usual effect of the double-click, i.e. opening a text/numeric/date field for editing, or launching the choices palette for a choices field.
Answering most of my own question, after a bit more thought:
Deselecting ‘Editable’ for the field in question makes sure the choices palette won’t appear in addition to the new popup menu.
Enclosing the click: code in an if doubleclick() ... endif structure ensures that the popup menu is only activated by a double click, just as the choices palette would have been.
Also, changing the second argument of popupclick from "" to «» ensures that the popup menu opens highlighting the current value of the cell, if any.
Thus Jim’s suggested code becomes:
return
click:
local choice
if doubleclick()
let choices= replace(getdictionaryvalue(getfieldproperties(),"CHOICES")," ",cr())
popupclick choices,«»,choice
if choice<>""
«»=choice
endif
endif
The remaining problem is a click within the data sheet window but not within a valid record/field cell. I wondered whether it might be possible to compare the co-ordinates of the mouse click with the rectangle describing the window co-ordinates of the currently selected cell in the data sheet, and only launch the popup menu if it’s within it. However, I’m not at all surprised that there doesn’t seem to be a function to return that particular rectangle — it wouldn’t have much practical use for anything else.
However, a double-click in the data sheet will usually be a deliberate act to modify a specific cell, therefore it is unlikely to occur in the dead area there might sometimes be to the right of the last field or below the last record. And single clicks in that area, which are much more likely, will no longer cause the popup to appear. Thus it’s no longer a significant problem.
So that has now done the trick very nicely. Thank you, Jim.
This is a fabulous solution that I modified to allow for choices with spaces in the choice names that can be identified with an underscore “_” in the list of choices:
return
click:
local choice
if doubleclick()
let choices=replace(replace(getdictionaryvalue(getfieldproperties(),“CHOICES”)," “,cr()),”_"," “)
popupclick choices,«»,choice
if choice<>”"
«»=choice
endif
endif
The icing on the cake would be to be able to copy the selected choice in a field from one record to the same field in another record but this is already 99% of what I was looking for.
Thanks for this wonderful and versatile tool that I use daily.