*New Multifact plugin

[ColeValleyGirl]

Colin, that suggests that all the other plugins you use don't rely on the pl library.

If you want to try it before we get to the root of the problem, as you've already got the pl library installed, you can change this line

Code: Select all

if not fhloadrequire("pl","pl.init") then return end -- Load required Penlight modules

to

Code: Select all

require("pl") require ("pl.init")

[tatewise]

I can't see anything significantly different in fhloadrequire between Multifact and Research Planner.
The require(...) for standard modules are in a different position.
Slightly different pl modules are required but that is after fhloadrequire("pl","pl.init")

So a useful test is do both Plugins currently misbehave for Colin ??
It would be worth downloading it again just to perform that test.


I have reviewed the boxes and tips a bit more for inconsistencies.

When first run, ALL the boxes are Active, including the conditional ones such as Place 2, Attribute & Cause.
Whereas, after Clear those boxes are NOT Active until a suitable Fact is chosen, which makes sense.

When all three expanders are open the bottom of dialogue (main buttons and Activity Log) are off bottom of my screen.
When all three expanders are closed the main dialogue does not shrink to fit (not a big problem).

If the main dialogue window is enlarged by user, all the boxes get bigger for more text, which is good.
But if the main dialogue window is shrunk by user, it can get much smaller than the controls, which is not so good.
My plugins cannot shrink the dialogue windows smaller than the minimum size of all the controls, but not yet sure how to apply that condition to your plugin.

The Tips should say Make Facts rather than create facts so they refer to the button label.
The Make Facts button does need a Tip.

The Note box now needs need a Tip regarding Auto-Create Notes.
Why can't this Note box content be appended to any Auto-Create Notes?

I wonder if there needs to be some introductory advice text at the top to explain what the plugin does?
e.g. All Individual(s) will get all Fact(s) with identical values derived from boxes below.

[Valkrider]

Helen

I will do some more digging this afternoon but it looks like one of the updates to Wine or the Mac may have messed with something.

I now get this error message.

Screenshot 2019-03-13 at 13.39.11.png (80.28 KiB) Viewed 1180 times

Looking in the pl directory none of those files exist.

[tatewise]

I've solved the expander Open/Close and minimum dialogue size issues.

You need a global function to refresh dialogue size and set its minsize such as:

Code: Select all

function refresh(dialog)
	dialog.size = iup.NULL
	dialog.minsize = iup.NULL
	iup.Refresh(dialog)
	dialog.minsize = dialog.naturalsize
end

Then for each dialogue call that function.
For dlgFacts in local function FactsChoose() call refresh(dlgFacts) before dlgFacts:popup(...)
For dlgage in local function AgeChoose() call refresh(dlgage) before dlgage:popup(...)
For dlgmain call refresh(dlgmain) after DoNormalise()
For each expander after visible = "YES"; add action = function() refresh(dlgmain) end;

With that in place the Activity Log can start in state="CLOSE".
In fact it might be better to start them all in state="CLOSE" as I didn't spot the Citation expander until I closed the others.

[ColeValleyGirl]

Mike, have you managed to assign a tip to a list without an editbox? I can't make it work.

re disabling Place2 etc on startup, I'm torn -- without a fact selected how can I know if they're valid or not? I can envisage a scenario where somebody fills in all the Fact details and then chooses the facts... annoying if they couldn't access fields they knoew were going to be valid.

[Valkrider]

I have spent the afternoon trying to resolve this and can't. Those files do not exist in those locations on my other Mac that uses a virtual machine, so I am at a loss. Why is pl needed for this plugin whereas others don't seem to require it.

[ColeValleyGirl]

Pl is a library that provides functionality that other plugins may not require.... the ability to use it (if a plugin requires) it is provided by Calico Pie.

[tatewise]

Regarding an iup.list with editbox="NO" and dropdown="NO" then tip="help text" works as elsewhere.
Which box are you having a problem with?

Helen, your argument about Place 2, Attribute & Cause applies equally to startup and after Clear button.
Both should behave the same way. Why should they behave differently?
On closer inspection, the Clear button does not change those box active states, but just clears their contents.
So they are left in an arbitrary state depending on which Fact(s) had been chosen prior to the Clear.
Thus the Clear button should make all three active="YES" to agree with current startup mode.
Alternatively, both startup and Clear should set all three active="NO".

Colin, see Knowledge Base > Family Historian Program Data Folder.
In Wine or Crossover on Mac the folder is C:\Users\Public\Application Data\Calico Pie\Family Historian\Plugins\
Whereas in Windows Virtual Machine it is C:\ProgramData\Calico Pie\Family Historian\Plugins\
Inside the Plugin, fhGetContextInfo('CI_APP_DATA_FOLDER')..'\\Plugins\\' should point to to correct folder.

[Valkrider]

@Mike

Thanks for that but what is the edit required? There is no reference to C:\ProgramData\Calico Pie\Family Historian\Plugins\ in the plugin code.

[tatewise]

Colin, I was not suggesting any edit, just that the custom data folder has a different path name in different OS.
So the \Calico Pie\Family Historian\Plugins\ has a different path in Wine/Crossover than in Windows.
Thus you won't find the Wine/Crossover path in the Windows Virtual Machine and vice versa.

The Plugin uses fhGetContextInfo('CI_APP_DATA_FOLDER')..'\\Plugins\\' to automatically use the correct path.
Run the Plugin in Edit/Debug mode with a Break on line 80 and storein will hold the correct path for the OS being used.

Running both this Multifact plugin and the Research Planner plugin on both OS may give a clearer idea of what is failing.

FYI: Different plugins require different Lua library modules depending on the functions they perform.
The most popular ones are built into the FH program along with the Lua interpreter and just need a require command.
Others must be downloaded from the FH web site into the Plugins folder and need the fhloadrequire process, but once completed should not need to be downloaded again, and just the require command should do.
The Knowledge Base > Getting Started Writing Plugins lists those two types of library module near the end.

[ColeValleyGirl]

Colin, it may be the first thing to try is delete the existing pl directory, in case its 'partial' presence is confusing matters?

[ColeValleyGirl]

Mike, for some reason I can't get Place2 to have a tip.

Re Place2/Caus/Attrib I agree they should be handled consistently and will fix that but am not convinced they should be disabled when no facts are chosen. I can envisage a way of working that extracts all the information from a source and uses it to populate the fact data before deciding what facts to make, so not being able to enter e.g. Attrib would be annoying.

[mjashby]

I've had a look at the problem Colin reported and can confirm that there is an issue if Mac Users do not have access to a genuine Windows installation of Family Historian with the plugin (or some installation that requires the 'pl' folder and contents to be downloaded) pre installed; i.e. On first run of the plugin you correctly informed of the need for 'pl' to be installed are invited to download the file/folder : Then on acceptance an error message pops up saying it cannot be downloaded at this time and please try again later. There seems to be an issue with all Wine Builds of Family Historian with some plugins that require internet access to perform downloads, but it does not seem to apply to all such procedures so is difficult to narrow down the specific cause.

Possible work arounds for Mac (or Linux) Users:

1. If there is access to a full Windows installation of Family Historian install the plugin and download the required 'pl' folder normally. Copy the resulting 'pl' Folder and its contents from the Plugins Folder Windows installation to the equivalent Folder in the Wine.app Build (Crossover, PlayOnMac, Wineskin or native WINE) and the plugin then works. Tested on both a Crossover Bottle and Wine.app built with Wineskin (my preferred option) and appears to be working, although the interface screen appears rather large on a MacBook.

2. If there is no direct access to a Windows installation, then a Mac (or Linux) User would need to be able to directly download the 'pl' Folder for manual installation.

Hope that helps.

Mervyn

[Valkrider]

@Mervyn

I tried #1 that you suggest but still it will not work. Any other thoughts?

[tatewise]

The IUP guide for iup.list under Notes says:

In Windows, if EDITBOX=YES then the tooltips are shown only when the cursor is near the control border or at the dropdown arrow.

I don't recall using iup.list editbox="YES" in my plugins, which either use iup.text or iup.list dropdown="YES", so never experienced that tooltip behaviour.

I'm content with however you choose to handle the startup and Clear button, as long as both produce the same state.

Mervyn, thank you for investigating the pl problem.
You are saying that if the pl folder and contents already exist, then there is no problem.
But on Wed 13th Mar 2019 09:00 Colin said: "Yes the pl folder is still there and has 39 items in it."
So, since the folder is present with 39 items, why does it still fail for him?

Colin had a similar problem in Research Planner Technical Nuts & Bolts (16411).
That was resolved by changing https: to http: in the download URL.

In the Plugin what status is returned at about line 97 ?

[mjashby]

Mike,

Not sure about the already exists scenario as I didn't have an existing pl folder and am not sure what other plugins or procedures might require or cause the pl folder and its contents to download to FH. I would suspect that in that situation, the plugin would just run without any problems, as that's what happened when I ensured that I had copied the required folder and files across to correct location in the Crossover/Wine.app. Should be easy to check on a Windows system, i.e. delete/move/rename the pl folder an the plugin shouldn't work (should ask for the download again); cancel and return it to the required location and the plugin should just work again.

Colin,

Forgot to mention that the first time I attempted to copy the pl Folder from my VirtualBox Windows installation I did find that the Folder was copied to a location on the Mac, but not the Folder Contents. I suspect it may have been a 'networking' issue when doing a combined folder plus its file contents in one step between the virtual Windows installation and the Mac. All I can suggest is to make sure the folder contents in your Crossover/Wine.app match those in the original Windows Folder. When I did that, it just worked!

Mervyn

[mjashby]

Here it is working in Crossover

[Valkrider]

Mervyn

Does your pl folder have anything other than lua files in it? That is all that mine has and yet the error messages indicated that some dll's were missing.

[Valkrider]

SUCCESS

I zapped the pl folder in PlayOnMac and copied again from my VM and the plugin is now working fine without the change suggested by Helen earlier in this thread.

[Valkrider]

@Mike

Is it worth adding a zip file of the pl folder to the KB? It may make it easier for people having similar issues.

[tatewise]

Yes, that pl ZIP file would probably just need adding to the Crossover/Wine folder, along with others as required.

It sounds like there was a difference between the pl folder that previuosly existed, and the latest one copied across.
Perhaps the library module had been updated in the meantime and needed a new download, which appears to fail on Wine.

With the pl folder missing, can one of you run the plugin in Editor/Debug mode with a Break on line 97.
What is in the status variable, that should contain OK?

[ColeValleyGirl]

Mike

For each expander after visible = "YES"; add action = function() refresh(dlgmain) end;

This approach means that if the main dialog has been enlarged, using an expander returns it to its minimum size -- is this what you expected?

[tatewise]

Yes, the dialogue automatically expands & contracts depending on which expanders are open or closed in any combination.
But in all cases the user cannot shrink the dialogue smaller than the displayed controls, but can enlarge it if desired.

Yes, currently if the user has enlarged the dialogue it will shrink when expander is changed.
It may be possible to retain the enlarged width, but not so sure about height as it has to be shared by the expanders.

My main concern was preventing shrinking to less than the displayed controls.

[tatewise]

I think this is an improvement that retains enlarged size but still enforces minimum size.
Change the refresh(dilaog) function as follows:

Code: Select all

function refresh(dialog)
	local strSize = dialog.size    -- Preserve original dialog size
	dialog.size = iup.NULL
	dialog.minsize = iup.NULL
	iup.Refresh(dialog)    -- Refresh to establish natural size and set minimum size
	dialog.minsize = dialog.naturalsize
	dialog.size = strSize
	iup.Refresh(dialog)    -- Restore original dialog size
end

Also add a resize_cb callback to main dialogue just before it is shown, so when shrunk the controls also shrink.

dlgmain.resize_cb = function(self) refresh(self) end

Similarly, just before the popup for the facts and age dialogues:

dlgFacts.resize_cb = function(self) refresh(self) end

dlgage.resize_cb = function(self) refresh(self) end

Interestingly, these two dialogues remember their size from one use to the next while the plugin is open.

[tatewise]

Colin, I've supplemented your Knowledge Base > Plugin Library Modules advice with a few more library module ZIP files.