Having checked, I can say that clicking the morph in the library does not transfer its function to the list of morphs resident on the list of parameters. This behavior appears, seemingly a random, with several figures. For example, the Michael 4 morphs Jeremy and Young and the Victoria 4 morph Young simply do not work. Clicking on these morphs in the library does not transfer their function to the list of parameters.

Occasionally, but more rarely, the morph appears in the list of parameters, but turning the dial has no effect at all.

Has any one had similar experiences? Does any one know how to fix the problem?

@abrahamjones if you have morphs which already have possibly hidden channels allocated for the same name, you need to check (Show Hidden morphs may show you a bunch of morphs whose external name is "-", but internal names match the empty morph slots) that the injection pose is setting the channel's "hidden" parameter to 0, to make it visible.

In the "Young" example, that morph is one of the standard morphs:
[Excerpt from the header of InjDeltas.FBMYoung.pz2]

Thanks very much for your reply. As far as Michael & Victoria 4 are concerned, there is happily nothing so esoteric as hidden morphs. I've done a little investigating and discovered that, in my installation, the V4 Young and the M4 Jeremy and Young are not full body morphs. They appear to be partial head morphs. For example, V4 Young references a file named InjDeltas.PHMHeadYoung.pz2. And sure enough, the parameter appears under the Morphs++ category when Head is selected. The same is true for M4's Jeremy and Young. All very unusual since these three morphs are presented as full body morphs in the readmes.

I'll do further research concerning morphs for the boots. And thanks again for taking the time to help. It is certainly appreciated.

On my computer, the Young.pz2 file references a file named InjDeltas.PHMHeadYoung.pz2, which resides in the !DAZ:Victoria 4:Deltas:Morphs++ folder. Of course, there IS a file named InjDeltas.PHMHeadYoung.pz2 file in the same folder and THAT is the morph injected when I click Young in the Morphs++ Library. The result is a morph that applies strictly to Victoria's saucy head and has no effect whatsoever on her sexy bod.

I strongly suspect that the Young.pz2 file should reference InjDeltas.FBMYoung.pz2, a file that also exists in the same Morphs++ folder but, so far as I can discern, is not referenced by any clickable tab in the Morphs++ library.

I have no idea how this appalling mis-carriage of justice came to pass, but there we are.

I may have achieved enlightenment. Upon checking the V4 Morphs++ list, I learn that there are in fact two young morphs: FBMYoung.pz2 and PHMHeadYoung.pz2. The second seems intended to complement the Old morph. However, there can be only one Young.pz2 file in the library. Mine references the second file. I suspect that I will have to add to the library a new file that references the first.
Thanks one and all for your interest and assistance.

@abrahamjones I assume you've run the :Runtime:libraries:!DAZ:DzCreateExPFiles... commands for V4 and M4? These parse the !DAZ folder hierarchy for all the currently installed morph injection packages and add them to the base injection files which the library morph injection poses refer to. By default, the V4 and M4 figures only include basic head morphs for expressions, and you need to add the Morphs++ and other morph packs to get the "Standard" full body morphs, including FBMYoung.

The addition of the appropriate files was a complete success; the "Young" problem is solved to my complete and entire
satisfaction. This is the first time I have dared to muck about with Poser's internal files and I'm going to let it go to my head for a hour or three. I shall have a glass of wine with dinner.

Thanks to all for their assistance and comments. You pointed me in the right direction.

@abrahamjones to be fair, these are not actually Poser's internals at all. the V4 & M4 Expansion Packages hierarchy was an invention of DAZ, leveraging the most out of what the Poser file formats (specifically the "readScript" command) and library loading processes allow. I find them extremely useful for allowing the re-use and modularity of common components amongst related figures.