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

For users to report plugin bugs and request plugin enhancements; and for authors to test new/new versions of plugins, and to discuss plugin development (in the Programming Technicalities sub-forum). If you want advice on choosing or using a plugin, please ask in General Usage or an appropriate sub-forum.
Post Reply
User avatar
Mark1834
Megastar
Posts: 2458
Joined: 27 Oct 2017 19:33
Family Historian: V7
Location: South Cheshire, UK

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

Post by Mark1834 »

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
User avatar
Mark1834
Megastar
Posts: 2458
Joined: 27 Oct 2017 19:33
Family Historian: V7
Location: South Cheshire, UK

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

Post by Mark1834 »

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: 28341
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 »

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
User avatar
Mark1834
Megastar
Posts: 2458
Joined: 27 Oct 2017 19:33
Family Historian: V7
Location: South Cheshire, UK

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

Post by Mark1834 »

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: 917
Joined: 15 Nov 2016 15:40
Family Historian: V6.2

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

Post by Ron Melby »

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: 28341
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 »

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: 917
Joined: 15 Nov 2016 15:40
Family Historian: V6.2

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

Post by Ron Melby »

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: 5465
Joined: 28 Dec 2005 22:02
Family Historian: V7
Location: Cirencester, Gloucestershire
Contact:

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

Post by ColeValleyGirl »

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: 917
Joined: 15 Nov 2016 15:40
Family Historian: V6.2

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

Post by Ron Melby »

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: 5465
Joined: 28 Dec 2005 22:02
Family Historian: V7
Location: Cirencester, Gloucestershire
Contact:

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

Post by ColeValleyGirl »

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: 917
Joined: 15 Nov 2016 15:40
Family Historian: V6.2

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

Post by Ron Melby »

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: 8508
Joined: 01 Nov 2002 15:00
Family Historian: V7
Location: Somerset, England
Contact:

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

Post by Jane »

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: 917
Joined: 15 Nov 2016 15:40
Family Historian: V6.2

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

Post by Ron Melby »

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