* Calling a plugin from a plugin (again...)

Writing and using plugins for Version 5 and above.
Post Reply
avatar
Mark1834
Megastar
Posts: 935
Joined: 27 Oct 2017 19:33
Family Historian: V7
Location: South Cheshire, UK

Calling a plugin from a plugin (again...)

Post by Mark1834 » 14 Sep 2021 21:15

I’m a bit confused about where it is possible for one plugin script to call another.

This iup button callback pauses execution of the calling plugin, hides the interface, passes control to the called script, and resumes when the called script closes.

Code: Select all

function btnCall:action()
	dialog:hide()
	dofile(fhGetContextInfo('CI_APP_DATA_FOLDER') .. '\\Plugins\\Demo.fh_lua')
	dialog:show()	
	iup.Message('Call test', 'Done!')
end
The called script just shows a simple message to confirm that it is running:

Code: Select all

require('iuplua')
iup.SetGlobal('CUSTOMQUITMESSAGE','YES')
iup.Message('Message Demo', 'This plugin is being called from another plugin.')
Everything runs as expected. However, if I call a more substantial plugin (Export Gedcom File is a good example), it is more complicated. The script runs, but has the calling script as its window title, so they are clearly not independent of each other. Similarly, if the called script uses fhOutputResultSetColumn(...) to display output, it is not shown until both plugins exit.

I've got a couple of examples of self-contained plugins that perform well-defined tasks where it would be useful to call them from another plugin, rather than copy all the code and have to maintain multiple copies if there are changes.

The last time this was discussed , the discussion seemed to suggest that even this limited calling wasn't possible. I don't want to get into the complexity of creating modules or libraries, but are there any general rules on where dofile() is appropriate and what its limitations are? It clearly works up to a point, but I couldn't find anything on the forum or KB.
Mark Draper

avatar
Mark1834
Megastar
Posts: 935
Joined: 27 Oct 2017 19:33
Family Historian: V7
Location: South Cheshire, UK

Re: Calling a plugin from a plugin (again...)

Post by Mark1834 » 14 Sep 2021 21:38

I can partly answer my own question. The called script can access global variables in the calling script, and if there is a function with the same name in both scripts, it is the called script version that is called in preference once dofile() has executed.

Perhaps I should view dofile() as effectively meaning "insert the called script here" - if they are well constructed to be aware of each other's existence, it should work fine, but they are intimately connected, rather than running in their own isolated spaces.
Mark Draper

User avatar
tatewise
Megastar
Posts: 22399
Joined: 25 May 2010 11:00
Family Historian: V7
Location: Torbay, Devon, UK
Contact:

Re: Calling a plugin from a plugin (again...)

Post by tatewise » 14 Sep 2021 21:55

I've never thought about doing that.
However, I'm not sure it is behaving in quite the way you think. [Until you answered your own question.]
If I understand dofile(...) correctly, it is executing the called script 'chunk' within the context of the calling script.
i.e. As if the called script were a function within the calling script.
That explains why the called script has the calling script as its window title, and the Result Set is not produced until the calling script terminates.
As you say, there can be variable name clashes unless the two scripts are designed to cooperate.

I solve that strategy by having modular script libraries and just copy & paste them into Plugins where required.
i.e. Rather like the Plugin Code Snippets from the KB.
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry

avatar
Mark1834
Megastar
Posts: 935
Joined: 27 Oct 2017 19:33
Family Historian: V7
Location: South Cheshire, UK

Re: Calling a plugin from a plugin (again...)

Post by Mark1834 » 14 Sep 2021 22:28

I’m usually very sparing with global variables, so I can see a place for this in the right circumstances. I’ll keep it in my back pocket for when a suitable situation arises.
Mark Draper

User avatar
Ron Melby
Megastar
Posts: 791
Joined: 15 Nov 2016 15:40
Family Historian: V6.2

Re: Calling a plugin from a plugin (again...)

Post by Ron Melby » 14 Sep 2021 23:59

I do my common function modularly by use of require.

require '_STD_HDR'
require '_STD_SYS'
require '_STD_GPS'
require '_STD_PRT'
require '_STD_TBL'

and so on.

If you need to have variables from the calling program in the called program, you could always set and get them in _G, as well. They die when the originating program dies.
FH V.6.2.7 Win 10 64 bit

User avatar
tatewise
Megastar
Posts: 22399
Joined: 25 May 2010 11:00
Family Historian: V7
Location: Torbay, Devon, UK
Contact:

Re: Calling a plugin from a plugin (again...)

Post by tatewise » 15 Sep 2021 09:35

Ron, it is not possible to use require like that in publicly published plugins in the Plugin Store.
Where would the user get all those _STD_... files from?
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry

User avatar
Ron Melby
Megastar
Posts: 791
Joined: 15 Nov 2016 15:40
Family Historian: V6.2

Re: Calling a plugin from a plugin (again...)

Post by Ron Melby » 15 Sep 2021 11:09

I understand it is not acceptable from the store, but it could be.
perhaps loadrequire.... in any case a system could be made to cover such common things in the language.

if he calls a program from a program, it would not be available from the store, either, its same-same.

And there are a lot of good plugins that will never be available from the store because of those issues.

I see it as a cost of doing business with fh at the moment.
FH V.6.2.7 Win 10 64 bit

User avatar
ColeValleyGirl
Megastar
Posts: 3088
Joined: 28 Dec 2005 22:02
Family Historian: V7
Location: Cirencester, Gloucestershire
Contact:

Re: Calling a plugin from a plugin (again...)

Post by ColeValleyGirl » 15 Sep 2021 11:55

Ron, plugins from the store have to be self contained except for the commonly used libraries which are supplied with FH7 or made available via load require in Fh6 (where appropriate).

User avatar
Ron Melby
Megastar
Posts: 791
Joined: 15 Nov 2016 15:40
Family Historian: V6.2

Re: Calling a plugin from a plugin (again...)

Post by Ron Melby » 15 Sep 2021 13:52

as I have said, I am well aware of that massive shortcomining.

Seems like if you have to run a plugin out of the folder plugins, and to kick it off it must have an fh_lua extension, that a subfolder named require or include would be a mechanism to run down the garden path to reusability.

loadrequire (insofar as it is programmed) looks for modules, packages, dlls, programs, includes, requires or whatever, and since there is a custom fitted lua for fh, it would be a small matter to customize that bit.

I also understand that the issue would shift to: well, what requires are universal enough, correct enough, and useful enough to include in the folder?

I do not see many plugins in the store of any 'heft' that are authored by more than a select few.

It is why I do not have plugins in the store, nor in the snippets section, because I do not have any plugin, nor many usefule snippets, nor even many requires that do not depend on other requires, I only need to format a name once. I only need to format a gps once, and so on. I am not at all saying that it is allowed in the store.

I, like mark, have a reticence to copy code over and over, and rather than the mechanism of dofile, I use require, lots of locals, some globals, and they are pretty efficient and that is me, That is not the policy of fh, and that's how that is for the moment.

And mark, the thing that happens if you have two or more functions with the same name defined over several programs is, lua will use the last one that is 'defined' (in other words it updates the 'namespace' with the last one it sees) not easy to overload like C, it requires some other programming techniques like-- function common(...) to mimic overloading.
FH V.6.2.7 Win 10 64 bit

User avatar
ColeValleyGirl
Megastar
Posts: 3088
Joined: 28 Dec 2005 22:02
Family Historian: V7
Location: Cirencester, Gloucestershire
Contact:

Re: Calling a plugin from a plugin (again...)

Post by ColeValleyGirl » 15 Sep 2021 14:05

It's also an issue of trust, of course. The common 3rd party libraries are widely enough used that any malicious content would have been found by now. Plugins that go into the store are reviewed for malicious code before they're approved, ditto the snippets. Personally I wouldn't want to use code that hadn't been reviewed.

As you already know, you can include your own modules in the plugins data folder without needing a subfolder although that wouldn't help you make your modules available to anyone else.

User avatar
Ron Melby
Megastar
Posts: 791
Joined: 15 Nov 2016 15:40
Family Historian: V6.2

Re: Calling a plugin from a plugin (again...)

Post by Ron Melby » 15 Sep 2021 14:21

I would hazard a guess that if such a scheme would be adopted, that requires that would be approved at the store level would be reviewed in like fashion, the text file run thru programs to insure their were not any malware embedded, and that even given that extra circumstance of a 'require lib' for common code system, it would not stop people from placing personal requires in their folder, nor making custom plugins in their plugin folder. It would only open a small window into the microcosmic world of fh plugin coding. No more, really.
FH V.6.2.7 Win 10 64 bit

User avatar
Jane
Site Admin
Posts: 8200
Joined: 01 Nov 2002 15:00
Family Historian: V7
Location: Somerset, England
Contact:

Re: Calling a plugin from a plugin (again...)

Post by Jane » 15 Sep 2021 15:07

The other major problems with modules is keeping them up to date on other users PCs. Even if they can be downloaded they would potentially cause problems if the modules are updated and break plugins which are expecting the older versions, or vice versa.

The problems caused by LoadRequire is a case in point, so I would not expect Calico to be happy to host multiple possibly conflicting modules for multiple authors.
Jane
My Family History : My Photography "Knowledge is knowing that a tomato is a fruit. Wisdom is not putting it in a fruit salad."

User avatar
Ron Melby
Megastar
Posts: 791
Joined: 15 Nov 2016 15:40
Family Historian: V6.2

Re: Calling a plugin from a plugin (again...)

Post by Ron Melby » 15 Sep 2021 15:38

there is no doubt that fh has a huge problem with versioning as it is. It would certainly exacerbate the issue, until it became bad enough to resolve.

fh is small potatoes in the pc world. Even the large potato folks have issues with bugs and versioning, and yet, here we are, us merry band of ruffians, trying to plod thru all the muck. And we call it progress. LOL. We laugh because its funny, we laugh because its true.
FH V.6.2.7 Win 10 64 bit

Post Reply