I started to evaluate PanoramaX, ti’s pretty convincing, but I have also been surprised to see that even simple procedures need some rework, but that should be OK.
One feature I do not like is that the Find/Select window is attached to the main window and thus masks part of it (contrary to Panorama 6 where it is separated and can be moved around and resized). This is a very easy way to look somewhere in the database when filling a new record. Just do Find/Select something, without further Select or Find, see what is needed, and do Cancel to get bak to the main window. To this effect it would be better if the Find/Select window was movable and would remember its position and size, once resized (at least for the current session).
Like many other issues brought up on this forum, this is part of the effort to make Panorama a modern Mac app. According to Apple’s Human Interface guidelines, whenever a dialog is associated with a document, it should be attached to that document as a modeless dialog sheet. The only time a standalone modal dialog should be used is when the dialog is not associated with any open document. If you look at other modern, well designed Mac apps you’ll see that they never use modal dialogs. Panorama 6 was chock full of modal dialogs – in other words, once the dialog opened everything else was frozen until the dialog completed. In Panorama X the only modal dialogs are for opening files and views – neither of which are associated with any existing document. Wherever possible, dialogs were completely eliminated (many dialog options are now in the property inspector panels), otherwise, modal dialogs were changed to modern dialog sheets.
When I first started I thought like you did – that I preferred resizable modal dialogs. However, that is not the standard, and modal dialogs are an immediate red flag that an application is archaic and doesn’t use modern user interface conventions. The good news is that now that I’ve been using dialog sheets for a while, I like them much better than modal dialogs. What’s super nice about dialog sheets is that the program isn’t frozen. For example, you can open the Find/Select dialog, and then without closing it go look at another window, for example a procedure, another database, or incredibly useful, the Help window can be accessed even when a dialog sheet is open.
So give it some time, I think once you get used to them you’ll find that dialog sheets are really great.
I agree completely and avoid modal dialogs whenever possible. Which leads me to ask, is the search/find feature (when clicking the box on the tool bar) written in panorama, and, if so, how can we see the code? I was hoping to learn more about how that was done. I am wondering if that would help find a way to avoid the Gettext statement? Sorry if you covered this and I am asking again; I vaguely recall that you did.
Yes, it is. Pretty much ALL of these features are written in Panorama, including the Sort dialog, Summarize & Analyze, Morph, Split and Merge fields, Open View, all the Blueprint dialogs, etc. All of these features are essentially “open source” – the source is wide open for you to look at and learn from.
The code and forms for the Find/Select dialog are in the FindSelectLib library. You can open this with the Open View dialog, or with the View Organizer wizard. The main procedure is FindSelectDialog, but there are about a dozen procedures that go into this. By the way, this was the first of these dialogs that I wrote, so it may not be the best example. If I was going to rewrite this from scratch, I would do it with the activegrid statement, which I wrote after creating this dialog. In fact the activegrid statement statement was created from code originally written for Find/Select, but I never went back and rewrote the Find/Select code using the activegrid statement. Also, Find/Select is possibly the most complicated of these dialogs, it took 2 or 3 weeks to write and debug this code.
If you do decide to open up and look at this code, be careful not to accidentally modify anything. Better yet, you might want to make a copy of the application and work on that.
avoid the Gettext statement?
If you just want to avoid the gettext statement, perhaps simply try supergettext, which is a version based on Panorama code instead of Apple’s native code. Of course you can also create your own form and use the rundialog statement, which also allows you to create a dialog sheet.
Thank you for your explanation and sorry for my ignorance in Mac app design.
I can easily leave with that, just starting introducing a new record as the last one and not as the first one, then most of the time not hidden by the Find/Select window.
Thus I would like to rephrase my wishes as follow.
It seems that the Find/Select window cannot be resized vertically for less than 14 records; could the minimal vertical resizing be smaller, one or two records for example?
Once the Find/Select window has been resized (horizontally and vertically) during one session, can this size be remembered for the session, or even better for that DB?
Clearly these are not so important requests, would just be easier (at least for me!).