Supergettext is ignoring font, size and style settings in b18. It also ignores options set in SuperGetTextDefaultOptions. Not certain when this regression started after having been fixed in b12, as I’ve only just started using it. Superalert and superchoicedialog repaired at the same time still seem to be working properly.
It appears to work for me. I tried this code:
letfileglobal phonenumber=""
supergettext phonenumber,{font=Avenir-Black size=24}
And this is what I got.
I am actually using b19, but I don’t think that makes any difference for this issue. But you should download and install it.
I was referring to the font, style and size settings of the caption. Like you, I can set the font, style and size of the entered text, but not the caption as documented:
You can also change the font, size, style and color of the caption.
supergettext CardNumber,{caption="Please enter your card number" font="Palatino" size=14 style=bold color="#999999"}
It’s not clear that the supergettext statement can differentiate between caption font options and entry text font options as currently documented:
The edited text normally appears in the standard system font, but you can change the font, size, style and color. This example changes the edited text to be blue, bold, 15 point Tekton.
supergettext phonenumber,{font=Tekton size=15 style=bold color="#0000FF"}
I expected the caption font options to be consistent across these related super objects (superalert, superchoicedialog etc) but in supergettext you seem to have applied the font options to the entry text and not the caption text as in the others.
Incidentally, I have switched to b19, thanks, and you’re correct about it not making any difference.
That’s a mistake in the documentation. There are separate options for the caption parameters: captionfont=, captionsize= and captioncolor. It looks like these options were documented in Panorama 6 but the mistake was made in the rewritten Panorama X documentation.
Also note that Panorama X doesn’t support the style option, instead you have to use a bold font (or italic, if that’s what you want).
I have submitted corrections to the documentation for this.
I regret to say that captionfont= and captionsize= do not work, while captioncolor= and captionheight= do work. (I experimented with captionfont= before I first posted, on the off chance.) In addition, the default caption height is almost nothing, so you have to set captionheight=2 for a single line of caption text to clear the top of the entry box.
Reported and fixed (for b20)
Don’t forget that you can create your own custom dialogs from a form very easily with the rundialog statement. Then you can arrange the dialog any way you want.
Thanks, Jim. I’m trying to reduce the number of forms (and procedures for that matter) which were so numerous in one of my databases that the View menu was almost three pages long and quite trying to use. Callwithin helps enormously, and so do functional SOs like supergettext and superalert.
Two more issues with supergettext:
Following entry, the return key does not implement the highlighted button and close the dialog unless the key is pushed twice. The first time only turns off the focus ring around the text entry box.
If bgcolor= is used, the color does not fill the entire dialog, it leaves a section uncolored, and the focus ring is hidden in the colored section.
Upon checking supertext found that the return key does not close the dialog no matter how many times it’s pushed.
Sorry, that should read
Upon checking superalert …
IMHO the blue default button does not react to the Return key, but to the Enter key. So on a Macbook, you would have to press fn-return.
Many PX blue default buttons do react to the Return key. But as you say the ones mentioned above, which do not, both react immediately to fn-return. It’s a pity that MacBooks don’t have an Enter key as the computers I program for do have them. So I’ve been mapping my MacBooks’ right-hand Option keys as Enter keys. The PX behaviour is the same as my initial comments about the Return key, so in PX there seems to be a difference between an actual Option key and an ersatz one. However in P6 my remapped key does activate all blue default buttons, exactly like fn-return and a proper Option key.
Thanks for your reminder about fn-return.
I’ve been doing that for years using the free tool Karabiner-Elements. Setting that up is one of the first things I do on a new computer.
SuperGetPassword has the same issue and getting users to know about and use fn-Return will likely fall flat. It’s a learned habit to close such dialogs with a Return key when keyboards seldom have an Enter key.
Setting the line to 1 has no influence on this.
In either of these dialogs the Return key has the odd behavior of adding a new line on the first press, then deleting all but the first character on the second. Repeated presses repeat this pattern.
Since I’m using a SuperGetText for entry of a UserName follow by a SuperGetPassword, I thought I could assign Return as a HotKey to simulate fn-Return then immediately undefine it after the user was logged in.
In spite of my thinking there is a way to simulate keystrokes, I have not found it.
Regardless, it seems that HotKeys don’t apply to dialogs.
If you use GetText instead the return key will work.
I was doing just that until it was decided that the password shouldn’t be displayed. So I switched to SuperGetPassword for the bulls. Then switched to SuperGetText for the User Name in pursuit of a consistent look between the tow consecutive dialogs.
Is there an option I’ve overlooked for secure text in a GetText or GetTextDialog? I didn’t see it.
It’s of course more work, but I would suggest that you make your own custom dialog instead of using two sequential dialogs. Then you can use the Secure Text option as needed. (And it’s really pretty quick to make a custom dialog with the Dialog Workshop.)
I just got back to this and have built my own. It was no big deal, but I do have to admit that I couldn’t find anything about the Dialog Workshop. The only mention in Help claims it was enhanced in 2016 but the documentation is under construction.
For future reference, how is Dialog Workshop accessed?
I have been playing with an alternate approach to this problem by combining both the user name and password entries into one dialog. This is what Login looks like:
I have it set up so that if a user enters either the Return or Enter key while in either of the text entry boxes it checks to see if there is currently a value in that box. If there is it then checks the other entry box for an entered value and goes to that entry box if it is blank. If however, the entry box itself is blank it will beep and stay open to wait for entry. If both boxes have values it closes the dialog and checks to see if the values match existing user data. If it does not match it reopens the dialog along with an error message ready for another try. The same action is also handled if the Log In button is pressed. I have also included support for a **Remember me" check box so the user would be signed in during that session.
I think this automates the sign in process to match normal usage elsewhere. You could alter the user data check to limit the number of false attempts if needed. In my example file I have the data sheet opened with user info on it just for testing and you would not have this in real use since it might be a security risk. 
The file is available here. Also note that I used a scheme not generally recommended to check for the Enter and Return in the text editors and the Log In button. This is code that is entered before the resume {} statement which is suppose to be the only code used. Works without any problems in my extensive testing. The file has an .Initialize procedure to set the variables and the LOGIN procedure which handles the sign in dialog.
Very cool Gary!
I would suggest adding the ability to tab from the user name to the password which is standard in these types of dialogs. When I enter a user name and press tab, typing wipes out the text in the username.