How would you get the working (active) layer from an embedded script?

[Rai López]

Yeah, I'm conscious not very probable! But everything has to be taken into account just in case, and more with embedded scripts in mind running all the time several times... That's why I said it hurts a little to me to try to include the logic for all the possibilities, even in this case where there are only a handful of them. BTW, I was fan of this way of changing the working layer by clicking on another one while pressing a modifier key without affecting current multi-selection that we lost time ago (when it not only worked for the top/bottom layer), so it can seem a little stilted way of moving between layers nowadays, but for me at least it was the daily bread (changes ).

And well, FWIW, the current implementation seems to be filling the bill for now, and I didn't remember I was relaying so much on it along the whole script (when I implemented it in the wrong way based on the simple "doc:GetSelectedLayer(0)"), so hopefully everything will be now more robust now and I hope it last...

[synthsin75]

BTW, I was fan of this way of changing the working layer by clicking on another one while pressing a modifier key without affecting current multi-selection that we lost time ago (when it not only worked for the top/bottom layer)...

Yeah, I thought I remembered that being a possibility once. Now we just have to ctrl-click twice to change the active layer in an existing selection.

And well, FWIW, the current implementation seems to be filling the bill for now, and I didn't remember I was relaying so much on it along the whole script (when I implemented it in the wrong way based on the simple "doc:GetSelectedLayer(0)"), so hopefully everything will be now more robust now and I hope it last...

Hope so. I worry about the performance of constantly deselecting and reselecting layers.

[Rai López]

Oh, yes of course! And thinking it twice precisely now, maybe it was a good change after all...

I worry about the performance of constantly deselecting and reselecting layers.

It worried to me at first too, but it seems to behave finely and since it's not something that is going to be running while working on viewport or playing (only while a dialogue is open actually, for now at least) I think the extra time it can take against a more efficient solution is bearable. If at some point I'd have to give more use to it under other situations where performance rules, I'll probably have to start considering another way to do it more in the line of the one already mentioned, or... (the perfect outcome) who knows if maybe at that time we already have an implemented way to do it!

[Rai López]

And talking about that... Do you thing something like can do "doc:GetSelectedLayer(-1)" (yeah, I tried it!) for getting the working layer could be like a good proposal for a feature request? I mean, it won't interfere with the current functioning of the method where already in use and the possibility of getting the working layer would be just there should you need it. But just a thought! Cause if for some reason it makes more sense to simply add a new method only for that like "doc:GetWorkingLayer()" or whatever, the way it were implemented would be the least important thing...

[hayasidist]

The underlying service is broken.

with (say) 10 layers, click to select one - and all is fine.
Ctrl-click to add to the selection lower down the list - that one gets the highlight, and is returned as the "working" one.
Ctrl-click to add to the selection higher up the list - that one gets the highlight, but the lower one is still the one that is returned as "working".

similarly with click, then shift-click to extend the range -- shift-click higher: still the lowest returned; shift-click lower: "all is well".

Which suggests to me that the layer with the lowest AbsoluteId is always returned as active from doc:GetSelectedLayer(0)
(even though the correct layer is active in the work area)

===

And talking about that... Do you thing something like can do "doc:GetSelectedLayer(-1)" (yeah, I tried it!) for getting the working layer could be like a good proposal for a feature request? ....

FWIW I tried doc:GetSelectedLayer() (i.e. a nil) and that worked exactly as a doc:GetSelectedLayer(0) -- which tells me that we "almost" have the suggested feature - but the service would still need to be fixed for it to work

[Rai López]

But I think that's the way it is intended to work, Paul (as much as I'd like it worked the other way around you say).

For the way it's used in the multi-layer official tools, it seems "doc:GetSelectedLayer()" simply provides a way to loop along the selected layers no matter which is the working one and which not, it simply assigns 0 to the bottom one in the selection and goes summing up till the top one on hierarchy. The problem here is that, for a tool, knowing which is the working layer is as easy as ask to "moho.layer", but from an embedded script POV, "mohol.layer" always returns the layer where the script is embedded, and this turns what should be trivial into an I think unnecessarily convoluted task... That's why I think a feature request makes sense, whether it be by reusing the existing method, e. g. as I said, or creating another one (or whatever that makes easy to can know which layer is the working one, an important aspect, from anywhere after all).

Well, that's what I assume, of course, but as I said for the way it's used I'm afraid it works as expected and, in any case, when it fails to work and returns nil it's just due to the issue of Moho randomly considering there are 0 layers selected at times.

[hayasidist]

But I think that's the way it is intended to work, Paul (as much as I'd like it worked the other way around you say).

Yeah -- you're right .. it does, indeed, seem to come back in the sequence of absolute Id without regard to which is the "primary" layer.

Completely agreed we need a "give me the active layer"!

[Rai López]

Totally, thanks Paul! It's nice to know it has support. I mean, maybe this lack has passed kind of unnoticed for a long time but it doesn't mean it's not important as soon as you want to start taking the most of embedded scripts extending possibilities to interact with user actions or along the whole project... so, well, I hope it pays off!

[synthsin75]

Yeah, this is a lot of hoop jumping just to find the active layer. Really should be some easy way for a layerscript to find out.

[Rai López]

Well thanks to everyone , I'll make the feature request at the same time I report the selected layers counting issue then, greetings!

[synthsin75]

Here's a much simpler and rock solid solution.

If you don't mind the user installing a tool, you can have something as simple as this:

Code: Select all

ScriptName = "syn_temp"

syn_temp = {}

function syn_temp:IsEnabled(moho)
	self.layer = moho.layer
	return false
end

Return false so it never shows in the tool window.

And then the layerscript can always read the active layer, like this:

Code: Select all

function LayerScript(moho)
	
	print(syn_temp.layer:Name())
	
end

[Rai López]

Hmm... I wouldn't have thought about that one! Although I'd have to test it more thoroughly to see if it would be consistent enough, because in first quick tests here it sometimes seems to return directly the right layer and other times it returns the previously selected one and then the right one, or something so... it well could be easily addressable, but I'd have to make some tests to really can say.

Regarding have to resort to another script only for this, I'm not sure about that point because I was precisely trying to reduce dependencies to the minimum... but, of course, I'm not saying it's not good to know! Indeed, in my case, it would have been just perfect if it had worked with a menu script instead, because that way I wouldn't have even needed any extra file, but of course menu scripts' "IsEnable()" function is not called frequently enough (indeed I think only upon unfolding "Scripts" menu), so my hopes were dashed...

But if I ended up turning the menu script into a tool (thing that I've already considered several times for other reasons) I well could made good use of this, so thanks for sharing it, Wes!

[synthsin75]

Yeah, menu scripts do only test for enabled when the menu is opened. If they tested as frequently as tools, you wouldn't have to hide these sorts of utility scripts in the tool window.

Layerscripts probably do run so often that they might catch the last layer and the current one, while changing layers. Should be easy enough to test for if the layer changed first. Since I don't know what you're intending, I really can't say what would work.

But more ideas are always good to have in reserve.

[Rai López]

But more ideas are always good to have in reserve.

TOTALLY! That, and try to look to this kind of issues from another POVs, what is in great part what this kind of posts are for, so thanks again

And indeed thanks to the fact you made me return to all this I think I've made a find! I'm still testing it, but it seems that "moho.drawingLayer" could be giving me EXACTLY what I was looking for, so (if no drawbacks arise) everything could be as simple as this after all:

Code: Select all

function LayerScript(moho)
	local doc = moho.document
	local selCount = doc:CountSelectedLayers()
	local scriptLayer = moho.layer
	local workLayer = moho.drawingLayer

	if workLayer ~= nil then
		print(selCount .. " - Host: " .. scriptLayer:Name() .. " - WORKING: " .. workLayer:Name())
	end
end

At first, being a property so apparently focused on drawing tasks, I thought it wouldn't return any working layer different from vector, but for some reason it seems to return it no matter its type. Which makes it seem like too perfect to be real and that's why I can't avoid to have my reserves about it until I do more tests... but, at first sight, it seems the way!

[synthsin75]

Wow, yeah, I assumed moho.drawingLayer referred to a vector layer.

I'll have to test that for myself.