* Show Project Statistics discussion

[Mark1834]

Couple of observations on this plugin prompted by the Lua Error in Show Project Statistics 2.6 (20118) thread -

To learn for my own plugins, the principle of what the plugin is doing looks fairly straightforward, so presumably the main programming challenge is to structure it to give an acceptable run time for large datasets?

The main menu window struck me as a bit unusual. You have fixed the minimum size, but not the maximum. I can't see any point in expanding it, as it simply creates whitespace alongside the display grid and makes the option buttons look distinctly odd. I can't think of any other apps that behave like that. Why not just fix the window size (you wouldn't need the restore button then), or is there a benefit that I have missed? It's only cosmetic, but it does impact user perception.

The display is a bit data-intensive, so a worthwhile future upgrade may be to respect the user preferred Screen Font Scaling where this is available (default to 100% otherwise).

Capture.jpg (18.76 KiB) Viewed 3172 times

[tatewise]

Most of my more complex plugins utilise a standard library for many of the display features.
That allows the main window to be resized and repositioned and remembered in a similar way for all my plugins.
Where possible, the IUP components also resize automatically, but not all of them support that ability, and the grid used in this plugin is unfortunately one of them. The Options tab in this plugin and many other plugins work rather better.

The Restore Defaults button does a lot more than resetting the size of the main window. Hover over the button for a tooltip or check the Help & Advice for details.

Screen Font Scaling is new in FH v7.0.9 and my plugins have provided font adjustment via the Set Window Fonts button for many years. They will continue to do so for earlier FH versions. Do you know where the Screen Font Scaling setting is saved?
I cannot remember offhand, but it may be Set Window Fonts changes to font sizes that need the main window to resize.

This plugin does a lot more than accumulate the statistics that are the primary focus of the Records and Facts tab.
Composing the statistics is no great challenge even for a large database. It is the Exception Reports as chosen on the Options tab that need rather more coding.

[Mark1834]

That's probably where modern plugins have an advantage over legacy scripts. My latest (as yet unpublished) revision to the Ancestry sync plugin reads the default font and scaling from the Registry and sets the IUP defaults accordingly (the code is in fhUtils(), but I prefer to use local functions). All the labels and buttons on the right hand side are set up in an iup.gridbox, and all the scaling is done automatically without the user having to do any manual adjustment (so there are no settings to have to save and remember).

IMO, it gives the plugins a much more polished and professional appearance, as they look and behave just like any other FH window. Images show the main menu with Times New Roman 8 and Britannic 20 (at half size). It's less code, so easier for me to maintain and others to crib from, and saves the user from having to faff about with font and size changes if they choose not to use the defaults (they would have changed them for a reason...).

Times New Roman 8

Times New Roman 8.PNG (36.42 KiB) Viewed 3141 times

Britannic 20

Britannic 20.PNG (132.59 KiB) Viewed 3141 times

Given that FH6 is now a small and declining market, it might be worth gradually introducing alternative interfaces that exploit the FH7 benefits and are only called if running under FH7 (assuming you have your interface drawing properly separated from the core plugin processing). FH6 just does limited scaling (such as stopping that rather odd button growth), but FH7 users get the full benefit of the improved iup.

PS - added in edit, as you mentioned the Options tab specifically - the buttons definitely look a bit odd when expanded (but as ever, that just my opinion, has no effect on the functionality, and is digressing from the original question again, so I'll shut up now...

Options tab

Capture.PNG (37.6 KiB) Viewed 3121 times

[jelv]

The main menu window struck me as a bit unusual. You have fixed the minimum size, but not the maximum. I can't see any point in expanding it, as it simply creates whitespace alongside the display grid and makes the option buttons look distinctly odd. I can't think of any other apps that behave like that. Why not just fix the window size (you wouldn't need the restore button then), or is there a benefit that I have missed? It's only cosmetic, but it does impact user perception.

Why would you fix the window width when the column widths of the tables it contains can be adjusted?

[Mark1834]

The individual column widths can be adjusted, but not the overall size of the grid. So I would ask the question the other way around. What is the point of being able to expand the window if the grid size is fixed?

My preference would be to either fix both, or use a resizable grid and allow it to expand to fit the available space (as in my example).

But in all things UI, there are no hard and fast rules. I'm just making suggestions for alternatives that weren't possible when the plugin was first designed.

[BillH]

Mark,

On mine, if I widen the window and then make a column wider, the entire grid becomes wider and fills the wider window.

Bill

[jelv]

The individual column widths can be adjusted, but not the overall size of the grid.

What?

Project Stats.png (41.95 KiB) Viewed 3105 times

[jelv]

The only minor gripe I have with this plugin is that when you Export CSV files the file for the data table is an absolute mess because of the carriage returns in the headings:

Data, Fact
Types ,Media
Keywords, Places ,Addresses,Occu-
pations,Religions,Groups
Castes,National
Origins,Education
Contexts,Physical
Desc.,Posse-
ssions , Titles ,National
Id. Nos.,US Soc.
Sec.Nos.,Source
Types
Totals,21,11,601,113,139,,,1,,1,,,,,7

Easily sorted by editing using pspad before opening in Excel or similar.

[Mark1834]

On mine, if I widen the window and then make a column wider, the entire grid becomes wider and fills the wider window

Thanks Bill, that’s clear. Mike seemed to saying in his answer that the grid couldn’t be resized, but I can see that the two step process does do it.

I still think it’s worth investigating whether it’s now possible to do all that automatically and integrate the overall look and feel more closely with other FH windows (at least in new plugins, and it can gradually be rolled out retrospectively where relevant).

[ColeValleyGirl]

Grids can be automatically resized with the window but the necessary magic incantations are as clear as mud in the documentation.

[jelv]

@Mark

I presume you know about holding the shift key down while resizing columns? (I only discovered it after dragging all the following columns one by one!)

[BillH]

I presume you know about holding the shift key down while resizing columns? (I only discovered it after dragging all the following columns one by one!)

John,

I know how to do this in Excel, but it doesn't seem to work for the columns in Show Project Statistics (or at least I can't figure out how to make it work).

Bill

[jelv]

You need to put the cursor over the divider between the column headings (the cursor changes from a + to a left/right arrow). What is misleading is that as you drag, nothing moves until you release.

[BillH]

John,

I know how to drag a column to make it wider or narrower, but maybe I'm missing something. In Excel if you use the shift key, you can select multiple columns and drag the last column and all the selected columns become wider or narrower.

How do you select multiple columns in the plugin? When I try this only the one column is made wider or narrower. Exactly the same as if I don't hold the shift key down.

Bill

[jelv]

Sorry, I was making a general point about the behaviour of tables and column resizing in FH. What's odd is that it's not consistent.

The table in the plug-in behaves fairly nicely, dragging the divider on a column header resizes that column and moves all the following columns, changing the size of the table. Holding the shift key changes nothing.

Editing the rich text in notes is different. Firstly you can drag the divider line anywhere in the table, not just in the header. Secondly a drag without shift affects the adjacent columns only, one becomes larger and the other narrower. To resize a column as you would in Excel you need to hold shift and it then resizes the column and moves all the following columns.

So I automatically use shift nearly all the time in both places.

Neither has the ability to select and resize multiple columns which would be very handy!

[tatewise]

A few comments:

You cannot draw any comparisons between FH Rich Text or other tables and Plugin grid tables.
The FH tables are implemented internally, whereas the Plugin grid tables are built using the Lua IUP library.

Yes, no doubt I could make all sorts of GUI improvements but I only have a limited number of hours available each day.
The recent pressure of FH V7 updates has put such non-critical niceties way down my to-do list.
As Helen says, the IUP documentation on how to automate such things is often very vague, needing much trial and error.

Sorry about the Show Project Statistics ~ Data.csv disrupted format.
Some extra data analysis was added that introduced the newline codes and the CSV export was overlooked.
It will be fixed in the next version of the plugin.

[Mark1834]

I need to develop my understanding of IUP, so I had a look at the expanding menu buttons for you. The two hbox containers (line 3332 for the main buttons and 3298 for the Exception options) are missing the Expand='NO' term. Add that and they still adjust to font size changes but not window resizing.

It's only cosmetic, but it does make the window behave in a more conventional manner.

[tatewise]

Mark, I have experimented with your suggested changes to use Expand='NO'.
Not only does it prevent the buttons from expanding when the window is enlarged, but it prevents them from expanding to the initial width of the statistics grids in the minimum size window.
i.e. They are bunched together towards the left of the window rather than filling the window width.

Users are only likely to expand the window when they choose to manually expand the grid columns &/or rows.
Then I think it looks neater if the buttons expand to the width of the grid.
We may have to agree to disagree.

[Mark1834]

No problem. My opinion is no more or less valid than any other. It's just that I can't think of any other apps that behave that way, and it's not how CP implement it in other expandable windows in FH. Buttons stay the same size (albeit usually centred rather than left justified, but that's a minor addition to the code).

But just as we say that FH is CP's app to design as they see fit, it's your plugin so you have free rein to follow your own preferences . Plugins are open-source, so if a user feels strongly about it, they can always change it!