ZBrushCentral

Plugin Re-Focus Hitch / 1st Click Issue

ZScripting Help
#1

I seem to be having an issue with my plugins that I don’t remember happening in the past.

When my plugin looses focus, and then re-gains focus, it ignores the first user click (at least as an action). The plugin regains focus, refreshes the UI (and updates any switches whose states aren’t being tracked by memory blocks), but doesn’t update the target switch.

So basically, the first click seems to act as a refresh.

Is there a way for the plugin to regain focus simply be expanding the sub-palette, allowing the first click to register as an action, not a refresh?

#2

I’ve just been discussing this exact issue (it’s been around as long as I can remember) in another thread, specifically my answer here: http://www.zbrushcentral.com/showthread.php?209363-plugin-UI-states-issue&p=1219579&viewfull=1#post1219579 (though the whole thread may be worth reading because of the problem of conflicts).

#3

Oh boy. I’ve refactored much of my plugin code to support shared modules (including UI objects and variable names).

I’ve been zscriptinserting them into my main plugin files assuming that everything takes on the plugin name as a namespace or something.

Do you think there could be conflicts now between more than one of my Plugins?

I’ll have to test this in the morning right away. Thanks for that info Marcus

#4

Don’t be too anxious, it’s just something to be aware of. In this context it only applies to the interface test in the startup routine - that checks that the plugin interface exists so that the routine doesn’t run when ZBrush is first loading the plugins. I’ve tried to reproduce the problem but not had any luck.

You can re-use variable names in different plugins because they only persist so long as a plugin is loaded, and only one plugin is loaded at a time. Memory blocks persist for the whole of the ZBrush session (unless you specifically delete them) and so you should be careful in naming - unique to the plugin (unless you need to access the block from another plugin) and avoid generic names such as “Startup_Mem”. I generally use my initials and the plugin name in memory blocks.

#5

Thanks for the information Marcus. I’m afraid I’m still stuck.

I’ve boiled it down the simplest example I could, forgoing my module usage, and setting up an example file that is almost identical now to the one pointed me to. I’ve even tried an extremely basic plugin that does nothing at all except makes two switches, and the ignoring of the 1st click still happens.

I don’t have a Startup routine myself, I’m not actually sure what is being accomplished by that startup routine either. Should I have one?

Any chance you could take a look on your side?

Thanks again

#6

The Startup routine is what stops the “2 click” behaviour. Basically what is happening is:

  1. If the plugin is not active the first click loads the plugin. This redraws the switch states so that they are at their defaults, or their memory block values if these are used. So if a switch is clicked it can appear to do nothing.
  2. A second click is necessary to turn the switch off or on.

What the startup routine does is get between the loading of the plugin and ZBrush setting the switch states:

  1. When the plugin loads, the startup routine checks if a switch has been clicked.
  2. If a switch has been clicked, it sets the memory block value to the opposite of what has been stored.
  3. When the interface is redrawn as a result of the click, the new value is used for the switch and the switch behaves correctly.

Also the startup routine has a check so that the code runs only if the plugin interface exists. Without this check the code would run when ZBrush is starting up (when it loads all the plugins in the ZPlugs64 folder) - there would be an error and the plugin fail to load.

HTH,

#7

Thanks so much again for this information Marcus. I didn’t realize that routine was so critical. You’re explanation makes a lot of sense. This is working beautifully now, and I never would have figured it out without your help :slight_smile:

#8

That’s great! :+1:

#9

Actually Marcus, one more quick question if you don’t mind.

Why the loop x100? If the ID is constant, and the index refers the index into the MB Array, what is the loop actually doing?

thanks!

#10

Yes, that’s bonkers. I think when I originally wrote the code I thought I was going to loop through the switch IDs in some way and chose 100 as a maximum for the number of switches and then never did it.

So the loop should only be x1 (which is all it does anyway). Although a series of [If] statements without a loop would work fine I like to use one to make the code a bit more readable, and I think this is the closest one can get in zscript to the “switch case” of C++.

#11

Awesome. Okay.

I wondered because I started duplicating the loop multiple times (because my memory blocks correspond to UI / function modules referenced by my main plugin function, for example: Perform On selections, global options, axis selections, and a number of others).

So… each module would have to have routines responsible for the loop check and the handling of it’s own memory block. Those routines would be referenced in the main function’s Startup Routine, and would be fed the WinID and IDX as argument values. This meant hundred of loops once setup in all my modules, and I wasn’t sure what the impact of that was.

At any rate… I’m almost done with this refactor. Thanks again! :slight_smile:

P.S.
All of this is making me consider setting up boilerplate zscript files, that can be morphed and injected by a python script into a main plugin function. I like to be able to re-use as much code as possible, and was re-using ui code in multiple plugins, UNTIL I had to start handling memory blocks for UI states. Maybe one day

#12

I don’t think there’s any reason why you couldn’t set the memory block name through a variable, and re-use code that way. I don’t do it myself because I prefer code to be as readable as possible but I think you could do it.

#13

I agree. I actually had it set up that way with functions that set / get that variable and refresh the ui. Referencing the memory block directly was easier to read and was less code so I did that too