ZBrushCentral

Question: Possible to assign or reset Window ID?

ZScripting Help
#1

I am trying to reinitialise a [ISubPalette,…] in order to change the on screen size/position of the created subpalette. I quickly found out you can do so by [IClose,…]'ing the palette and reloading the Zplugin. It worked fine and nothing seemed amiss.

But after spending many hours rewriting 6-7 zplugins I discovered the Window ID assigned to each reloaded [ISubpalette,…] and [IButton,…] is set to the last available Window ID for Zplugins.

For example, <b>Zplugin &gt; TVTools &gt; MyZplug</b> has Window ID 13090 when Zbrush starts. One of the functions of my Zplugin requires <b>Zplugin &gt; TVTools &gt; MyZplug</b> to be redefined. I do so by [IClose,...]'ing it, which deletes the ISubpalette and any interface items within it, and then redefine the ISubpalette and the interface items within it by reloading the Zplugin. The only problem now is the Window ID is 13120 (for example). The next time I activate the zplugin the Window ID is 13128, or about that, all depending on how many interface items are to be put in <b>Zplugin &gt; TVTools &gt; MyZplug</b>.

This might not seem a problem but as ZPlugin Window IDs start at around 13000 it is only a matter of time before the assigned Window ID overlaps the other ZBrush interface items. Yes, I did sit and click until I reached around 33000:laughing:. At that point the Window IDs of my Zplugin was set to 0 and modeling and drawing on the canvas slowed down dramatically.

So [i]please[/i], does anyone have the patience to give this a shot. I am pretty sure it is impossible to redefine the ISubPalette using ZScripting but perhaps Pixolator could supply a .dll that could redefine a SubPalette's 4 inset values without deleting it? Or perhaps I have missed something?

Edit: Why is this necessary? Well, I will just say that it will help create a whole new form of Zplugins. Zplugins with pop up interfaces that remain active while you draw or sculpt, and can be moved like a regular window. ZPlugins that can “dock” to the bottom of the screen. Zplugins that you can shift between like Zscripts and even ZPlugin interfaces that can collapse or expand while on the canvas with little to no extra coding.

I will post some code once I have commented it sufficiently.

#2

Hi Mark,

Yes, I did sit and click until I reached around 33000

Blimey! :roll_eyes:

This sounds very interesting and I’ll certainly have a look (although I’m sure this is beyond my abilities).

#3

What a clever idea -very powerful potential!

If the only problem is resetting the existing subpalette’s inset values, I bet a .dll could do that. Whoever provides it will likely have to have some special knowledge of ZB innerworkings… I wonder if Pixolator is around? :roll_eyes:

How was it down under?

Sven

#4

Hi my friends,
i sincerely admire all of you coders…you navigate in ocean without any help…no compass at all.
I hope Pixologic will give you some money.:wink:

Thanks for the info.

cameyo

#5

Sorry for the delayed posting of the source code. I have been way to busy. Please excuse me.

First of all, a couple of notes on why the script works:

1) By defining an [ISubPalette,…] outside any existing subpalette you get a subpalette that exists within the ZBrush main window. For example, [ISubPalette, “Floating”] defines a subpalette within nothing, and is placed within the Zbrush Windows available space (Top left corner to top right corner to be exact).
2) You have to define a button, switch or slider into the above [ISubPalette,…] before it will show.
3) The [ISubPalette,…] inset values can only be changed by deleting the [ISubPalette,…] and then reloading the script.

      And a couple of reasons why it does not work:

1) Zscript generated items are automatically assigned a new Window ID which only increments according to the last Zscript generated Window ID. The value increases steadily, eventhough there might be unused lower values.
2) By deleting the [ISubPalette,…] with [IClose,…], which is currently neccesary, you are also deleting every interface item within that subpalette. Reloading the entire script is then neccesary.

What I would really like is some way to set the Window ID of all zscript generated items, of course checking them against already existing Window IDs. Being able to change the [ISubPalette,…] inset values would be nice, but to really make the most of this framework it is still neccesary to delete buttons and reload the script in order to change bitmaps assigned to buttons(Thus allowing a floating material loader, for example). Of course you could add that as another wish; being able to change the bitmap of a zplugin interface item without reloading.

Anyway enough talking. The script code is below. Unzip to a familiar location and run the “Framework.txt” script from there. The other .txt files should not be run, although nothing bad will happen if you should do so.

I hope everyone realises the possibilities with this script framework example. All the possibilities mentioned in my first post are not coded into this framework.txt but they are entirely possible. I am just worried it can/should all be made much easier by the [IDialog,…] command in ZBrush 2.5.

 A bit late but,
 
 Happy new year and Happy ZScripting
 
 Mark
 
 <b>-------------------------------------------------------------------------</b>
 
 <b> Mark</b>: Thanks for looking Mark, I hope you can get something out of the script code. Regarding the testing to window ID 33000, well I did increase the button count within my subpallete to about 40, so it did not take that long. Although I must admit after all that clicking I did have great difficulty in picking my nose. I kept hitting my eye instead. True story.
  
 <b> Svengali</b>: Thanks for the encouraging words. To make the idea really work it would be nice to be able to delete interface items and restore them again with the same windows ID. That would allow the changing of bitmap assigned buttons.

Down under was great although it drew out a bit longer than I wanted it to, I only got about 1 week off by myself. The weather was great and everything but the longer I stayed the more I worried about home and what was happening on ZBC :smiley: Still a great work experience.

 <b>Cameyo</b>: Cheers Cameyo, but this is the fun part, finding something "new". It does not really matter that it does not work perfectly right now, there is still the possibility.
#6

I forgot to add a couple of things.

Try click dragging the Title bar.

The close button ( X ) will in fact close the window and the code supplied does not have any way to open it again. You will have to reload Zbrush to start the script again. A script like this would usually have a button positioned in the ZPlugin palette which would activate the script, either through a shortcut or the press of a button.

When pressing the X button the script does not [IClose,…] the subpalette but [ IHide,…]'s it. This opens up for the possibility of an albeit unmovable floating palette, but at least a hideable floating palette. [IHide,…]'ing and [IShow,…]'ing a subpalette does not compromise the Window ID assignments.

Oh, and please ignore the TV01_Example memoryblock generated at the start. It is completely irrelevant to the code that follows. Sorry :o

#7

Well I gave this a run through and I haven’t been able to find a way around the window ID problem. It seems that once a zplugin has been loaded at startup there is no way to change it other than by using your IClose method. The whole lot, including button icons, is static in memory and is simply recalled rather than reloaded.

This is a great shame as I can see that this could be very useful. I think the fixed floating palette will be handy for certain scripts but it would be so much better to be able to swap button icons and so on.

#8

Thanks for giving it a shot Marcus. I did not get any further either. To bad. Oh well, on the bright side I do like making graphical interfaces for Note windows.

It is however possible to swap buttons and such, contracting and expanding the interface and closing the interface entirely without messing with the assigned window IDs. The problem is just moving the interface.

#9

OH, so how do you swap button images for a plugin? I couldn’t get that to work, other by using the IClose method.

#10

Ooops, sorry about that Marcus. I did not read the ‘icons’ part. No, graphics assigned to buttons are still not swapable but the buttons are through [IHide,…] and [IShow,…].

So in theory you could have a limited range of swapable graphics on the buttons by having multiple versions of the buttons. But in practise that would be a bit… meh.

#11

TVeyes -

This is really cool. Thank you so much for this idea. :smiley: This could be very useful for ZScripting in general and give ZScripters much more control over how they interact with users, obtain data, present feedback… Really cool. :slight_smile:

r