* GRO Source Reference plugin

[ChrisRead]

[This thread has been moved from the Question about scope of records handled by A.S. (22843) topic.]

I'm not sure I would really gain much from the plug-in as-is, although I may have a look at it to see if I could make some enhancements (as a learning exercise and if I can drum up the enthusiasm) such as format options and convert to citation from note, but that's for another day (month, year).

As it turned out, "another day" was the next day. I was intrigued, so had a go at re-working Mikes plug-in to be more like what I was after. I only write this here because it relates to the original posts in the thread when the plug-in came up. Oh, deity, the iuplua documentation is full of information, but not good examples for doing things that are not bleeping obvious. Doing the UI changes has been the main work, and I now need to plug back Mikes code that actually does the source citation stuff (software development is mostly plagiarising existing code after all ).

Key things I have done are to:

• Separate out some of the fields.
• Enable/Disable fields when relevant to selected options.
• Added customised GRO Reference formats for each registration type. These can be user defined using auto-text fields.

This has addressed things I personally wanted to change, in particular I wanted to change the output format of the GRO reference to what I use. It has been a 'nice' introduction to LUA and IUPLUA. As to whether the final result would be worth anyone's use, or being adding to the plug-in store, who knows.

Anyway, here's a couple of screen-shots of the main dialog and the format customising dialog.

GRO Source Main.png (23.67 KiB) Viewed 890 times

GRO Source Customise.png (9.94 KiB) Viewed 890 times

[Gary_G]

Chris;

Could you post something to show the format of the output citation(s) and perhaps if/where one could obtain the plugin?

[tatewise]

Chris, you are correct that it often takes much more software sweat & tears to modify the UI than the data rules.
Your enhancements are quite neat but I suspect they still do not use any Citation Templated Metafields.
Different users may define different Citation Metafields for GRO Index data, so a plugin that auto-completed such fields would need to be customised for each user's templates.

To make a plugin available to download use a cloud store (e.g. OneDrive or Google Drive) and post a Shared link.

[ColeValleyGirl]

a plugin that auto-completed such fields would need to be customised for each user's templates.

Umm.. No. Although it would be easier if customized templates used the same field names and types where possible,

[tatewise]

But what would happen if they did not use the same field names?
Anyway, I suspect the plugin does not even use the Essentials - Civil Registration Index - Citation-specific fields.

[ColeValleyGirl]

But what would happen if they did not use the same field names?

Defaults, Mike. Although my plugins (currently for private use) try various field names/types if possible before defaulting.

[Gary_G]

Chris;
The input form looked reasonable. I was just hoping to see how the output looked.

[neil40]

Chris;
The input form looked reasonable. I was just hoping to see how the output looked.

I got the impression that Chris had done the UI work from his screenshots, but was working on the code to create the output and ultimately the finished plugin

[Gary_G]

Ok. I misunderstood. I thought he had the whole plugin working.

[ChrisRead]

Ok...

This evening I munged in the update code from Mike's original with some adjustments to work with my UI changes (where I've basically binned the use of iup.GetParam() as I wanted to be able to dynamically alter the availability of various inputs based on selections. A perennial bugbear of mine is inputs that are not applicable to the current state of an App or telling a user off for doing something you allowed them to do, when you should have disabled his ability too do so in the first place (basically good UI design).

As for the output, it does exactly what Mike's version did in so far as where it puts the citation i.e. Event Note/Text from Source/Where within Source. It does not support templates any more than Mike's did as it's literally his with a souped up UI and some extra features.

Also, the screen shots actually show what you will get written to the Event Note/Text from Source/Where within source in the 'GRO Reference Preview': on the main screen. I put that there so the user can see if they forgot to select the format they wanted, and reselect.

The customisation screenshot shows the way the example on the main screen was defined using the auto-text style fields. You can pretty much define what ever formats you want as an output style, and they get saved as part of the plug-in data. You can define as many as you like for whatever reason for each register type.

I hope that clears a few things up. It's my first plug-in (and use of LUA and IUP) and less than a week from starting work on it, so I'm pleased that it at least does the things that Mike's previously did and my enhancements work well. I need to do some drastic tidy ups as I feel the code is a bit messy and not well organised. Need more locals and black-boxed functions to help with that.

I think I'd like to do some date dependant field enable/disable or even auto-filterable formats based on date as some formats only really apply to certain periods of time. That's for another time, lets get V1.0 completed to my satisfaction first.

[Gary_G]

Thanks for the insight, Chris.
I look forward to seeing the v1.0, whenever you get it to your liking.

[ChrisRead]

Mike

Chris, you are correct that it often takes much more software sweat & tears to modify the UI than the data rules

40 Years of software development confirms that, so what did I expect.

Your enhancements are quite neat

Thanks, I was surprised how simple the auto-text format definitions were to do.

I suspect they still do not use any Citation Templated Metafields.

Correct as it's just yours with enhancements. Also, I don't use them in FH, so am not familiar with them in the slightest, as I'm a basic user of FH. Once this is over and done maybe I'll look at what the templates are all about and if/how they'd fit in the paradigm of this plug-in.

[ChrisRead]

Ok, it seems to function at least as well as the original from Mike, although there are still a couple of things I'd like to improve on. So, if anyone is interested in trying it, here's a link you can download the file from:

https://1drv.ms/f/s!AiYzLSvsh206mPNdoHjIn_UAOc_pqA

It does no more or less than the original insofar as what it does in the FH project, and has mainly been an exercise in how to do an FH plugin, in particular learning about LUA and IUP.

The vast majority of the effort was in using IUP to rework the UI to be more dynamic and try to steer the user. Also, the addition of customisable GRO reference formats which are saved/loaded with the plugin settings (see your project folder 'Plugin Data'). Only note here is that the 'Where in' citation option is a single line and you may wish to define a suitable single line format if that is your way of working.

The plugin is aware of the GRO recorded information changes over time, so enables/disables or renames some fields as applicable, but I've not dealt with Age at Death v DoB yet.

Feel free to play with in, usual caveats re: use a test, or copy of your project or the FH sample. It should be possible to work out how to use it.

If you look at the code, it's still a bit messy, but if it is well received, I'll get round to tidying it. Also, please be nice, I did this as a fun exercise, don't make me hate 'users' , Mike and Nick know what I mean, I'm sure.

[Gary_G]

Thanks for taking the time to write the plugin.
It should be rather useful.

[ChrisRead]

Thanks for taking the time to write the plugin.

The time wasn't too long surprisingly, although my wife probably thinks she's a widow.

I learnt something new, and haven't written any software since retiring in 2020, until last month when I wrote a C# program with Access DB to replace my Parish Register reference spreadsheet. It was quite clever, but really needed to be moved to a database. That rekindled the developer in me, so when Mike's plugin was mentioned way back at the start of this thread, I looked at the code and thought, hmm, that looks not too complex to re-work for how I'd like it. Boom, here we are a week and a bit later. I can't say it really gets into the real nitty-gritty of the FH API, so that'll be something to learn in the future.

[ChrisRead]

I uploaded a V1.1 because I had a logic error in the UI enable/disable when the year was before Q3 1837 which also caused the citation formats to not be loaded to the drop-down. Also, I split the death Age from DoB, so they are no a common value and changed {BIRTH} to {DOB}.

[ChrisRead]

I have uploaded V1.2, which adds the final feature I wanted. It now allows the specification of a date range to a format definition, which is used to filter the format selection list. Depending on how you work, if you only have a single format style defined for a period, it means only one format is offered, in effect auto-selecting the format for the register and date you have entered.

If you want to see my set of formats covering the GRO timeframe, then delete your settings file and it will load the default set when you run the plug-in. Otherwise, your existing formats will be loaded, but simply have no date range (so not filtered) and you can update them as you wish using the customise dialog.

I also made a minor change to save the register selection for convenience, and bumped the data version. The plug-in will load older V1 data and default to births register until saved as V2.

I now need to go and find out how to get this into the plug-in store, as I think it is worthwhile, and adds features well beyond the original version, even if it basically does the same thing.

[Mark1834]

Check out the Authors' Area in the Store. CP actively encourage overlapping plugins, in order to give users a choice of UI styles, options, scope, etc.

All plugin submissions have to be approved by Store admin, but they are checked for malicious code only, not for function. Any accompanying help documentation is not moderated.

[Gary_G]

Chris;

I tried v1.2 and it works fine. Thank you for taking the time to polish it up.

[ChrisRead]

This afternoon I went through the process of getting an account and putting it in the plugin store. Remarkably swift response to requesting an account. You will need to view the All Plugins List and look for GRO Source Reference. It says there is no help, but I have just published the help, and I think it will automatically get linked to the plugin page once it's reviewed and allowed.

So, that's it, a nice week or so of learning something new, and getting as far as handing it over to others in the official way. I'll be removing the share I was using as you can now get it in the plugin store.

It just disappeared again, I suspect because I centred some images on the plugin page, and it decided it must be in draft again. So, I re-published to I hope make it come back. Maybe the Help link will get added too.

[tatewise]

Yes, even the slightest edit to the Plugin Download Page requires to be approved.

In your Help page have you linked it to the plugin and tick Main Page Yes in More Fields at the bottom?

[ChrisRead]

Hi Mike,
Yes, I figured I had to wait until the plugin published, so it would appear in the list I could link to. I then added the link before publishing the help. However, as I realised I should have centred the images for the plugin info page, I did so, but discovered that it had now gone from the all plugins list. I figured it must be because I had made the page text tweak, and it was draft again. So, I've re-submitted it and will see if the help lost the connection, otherwise I'll have to re-link it again. I did tick the main page yes in the help.

Just checked and the Help is published now, but still waiting on the plugin to update to see if it's hooked up correctly.

BTW Mike, I ended up entering the plugin version history multiple times as it didn't seem to get saved when I did something like add an image (TBH can't recall exactly what I did, just mildly p'd off). Twice I put in the full history from the source code, but the final time I could not be bothered again and just said go read the source.

[tatewise]

I've not had any issue updating the Version History, but maybe it is different for brand new plugin.
Mark has had problems attaching Help to the plugin. We are not sure whether it is just a slow automatic process or somebody behind the scenes sorts it out.

[Mark1834]

It's interesting comparing the Plugin Store and FHUG KB. They are both WordPress sites with broadly similar editing processes, but the latter has a far more polished feel about it, principally from the work done by Colin Spencer and Helen Wright to design and build suitable templates. The Plugin Store is much more basic, with numerous gaps in functionality that clearly haven't been regarded as worth fixing for such a small user cohort.

[ChrisRead]

Well it's all present and correct now and the help seems to have hooked up to it as well. What next? a small tweak to split the age/dob internally to treat as if separate values for the format, and any bugs that come up.

such a small user cohort

Yes, was surprised how short the list of all authors was. I'd assumed loads.

Is this plugin group friendly and helpful, and who's the iuplua expert. That was the most frustrating bit as it was the majority of what I did was trial and error poking iuplua.