Yes... the git hub repository is a 3rd party whose TexToMatO script was blocked by my simpler one when the simple one was pinned to a toolbar. The simple script did not block TexToMatO if the state function was removed. Which in my case... did not seem to be needed.

But it indeed sounds like the 3rd party TexToMatO script is doing an action that is not proper in the first place. So, it is likely to have other unforeseen issues. I will let the developer know about it.

The script we created at work was simply assigning object to a default layer if they had no assignment. It had no ui dialog but did have a state function that served no real purpose. But just having the event affected an unrelated script causing its ui to be blocked.

The script that had its ui blocked when the other script was docked to a toolbar was not mine. it was this one.
https://github.com/HerzogVonWiesel/TexToMatO/
Note that script also requires these python libs.
https://github.com/HerzogVonWiesel/Custom_Redshift_API

You should be able to see what I am talking about if you try to run TexToMatO. When any basic script that has a state function is docked to a visible toolbar TexToMatO won't draw its ui window.

We had a very similar issue. Only our viewport was fine, but a script that had a def state() function in it prevented another python script from drawing it's UI. So that script would bring up a window with no content in it.

Once we commented out state function everything worked fine. I think we only had it in there from copying some online examples. If I use the script editor to make a blank script, I noticed that the sate function is already commented out in it. Seems like it is best to avoid using it.

I would love to hear a comment from a SDK Specialist on the state of this bug in C4D 2003.2.2.