About Color Wheel

[ReMake]

I use in my effect Color Wheel control with PrimaryColor (for example, blue) by default. After applying the effect, I changed the PrimaryColor in the 'Colors' window from blue to red. Then I again called (restart) this effect, but the Color Wheel still had a blue color.

 

Is there a way to set the color for Color Wheel for each call of effect, which will coincide (correspond) to the new (changed) PrimaryColor from window 'Colors'?

[BoltBait]

I'm not sure there is a well behaved way to do what you want.  There are many things to think about, like the user pressing Ctrl+F to repeat an effect.

 

But, you could try something like this:

 

#region UICode
ListBoxControl Amount1 = 0; // Color|Custom Color|Primary Color|Secondary Color
ColorWheelControl Amount2 = ColorBgra.FromBgr(0,0,0); // [Black] {Amount1} Custom Color
#endregion

then, later in your code:

void Render(Surface dst, Surface src, Rectangle rect)
{
    ColorBgra PrimaryColor = EnvironmentParameters.PrimaryColor;
    ColorBgra SecondaryColor = EnvironmentParameters.SecondaryColor;
    
    ColorBgra mySelectedColor = Amount2;
    if (Amount1 == 1) mySelectedColor = PrimaryColor;
    if (Amount1 == 2) mySelectedColor = SecondaryColor;

    :
    :
    :

}

Untested, but you can try it.  

[ReMake]

Thanks for the answer.

 

Let's say the effect has only one control - Color Wheel. In this case your solution is not exactly what I'm talking about. After the first start of effect the Color Wheel accepts PrimaryColor color. Then, when I will change color in the 'Colors' window, I want that again started effect has accepted this new color, but Color Whell keeps PrimaryColor accepted at the first start.

[BoltBait]

48 minutes ago, ReMake said:

Let's say the effect has only one control - Color Wheel. In this case your solution is not exactly what I'm talking about.

 

That's why I said...

 

1 hour ago, BoltBait said:

I'm not sure there is a well behaved way to do what you want.

 

And then I offered you a way to do it if you are designing a new effect where you need this capability.

[ReMake]

Thanks for the clarification.

[BoltBait]

The thing is...

 

When you start an effect, the UI is prepopulated with what is stored in the effect token.  If it is a fresh run (nothing stored in the token yet) you get the preprogrammed initial values.

 

When you press OK to finish an effect, that color is then stored in the token for use next time.

 

So, when you start the effect the second time, the UI is prepopulated with what is stored in the effect token... the values from the previous run.  That's why you're getting a color other than the Primary color.  This is handy if someone presses Ctrl+F to repeat an effect.  That way, you get the exact same effect with the same parameters. 

If your effect is based on IndirectUI, that's where it ends.

 

Now, if you code your own effect NOT based on IndirectUI, you have control over the token and prepopulating the UI.  So, you are free to make this work any way you want, including always setting the default color to the primary color.  This will have the consequence of breaking Ctrl+F as you will always get the Primary color instead of the previously used color. (This may be your desired behavior and you may not consider it broken.  )

 

But, this is a lot of work.  And, it may just be easier to use my suggestion above if you are wanting the Primary color instead of what is stored in the token.

 

[ReMake]

Ctrl+F!  I forgot about it!

 

32 minutes ago, BoltBait said:

And, it may just be easier to use my suggestion above if you are wanting the Primary color instead of what is stored in the token.

 

It was the attempt to find the solution in the program way.

 

Thanks for a detailed explanation once again.

[Ego Eram Reputo]

Time to migrate to Visual Studio? VS gives you fine control over tokenization of the controls.

[ReMake]

2 hours ago, Ego Eram Reputo said:

Time to migrate to Visual Studio? VS gives you fine control over tokenization of the controls.

 

Work in VS not a problem for me. But also there is no wish to be beyond IndirectUI too.

[oblivioncth]

While working on a plug-in I realized that I have the same problem that ReMake talks about in that I'd prefer the Color wheel get reinitialized with the current Primary color each time the effect windows is brought up. I am able to use the strategy BoltBait mentions in that thread to get around its current behavior and always grab the primary color, or offer the user the option to use the primary color or the color in the wheel through a radio button group, but it just isn't as clean, especially since the color in the color picker won't get updated even if the user selects the primary color option (unless there's some way to grab the instance of whats rendered onscreen and change the form parameters through the IndirectUI framework that I haven't caught onto yet, though I don't think there is).

 

This doesn't ruin the plug-in, just makes it a bit awkward. Reading through this thread lead me to develop a few thoughts/ideas. BoltBait listed two main reasons as to why the effects behave the way they do currently:

 

1) Many effects rely on the convenience of being able to use them multiple times, perhaps often with slight changes, so the convenience of being able to reopen the tool and have the previously applied settings retained in the window is significant

 

2) As an extension of the above, changing this behavior and this behavior alone would potential break Ctrl+F depending on the plug-ins intended use since using the "Repeat...X" option would use the new colors instead of the old ones.

 

Point 1 is just a side effect of how the current token system works (from what I understand and what BoltBait explained) and I can't see being any trouble to change as the PropertyEffects could just be fleshed out a bit more to include a true/false parameter (which then could be forwarded to an option in CodeLab) on whether or not to hold the previously used values or reinitialize from default. No problem.

 

Point 2 on the other hand surprised me a bit and made me want to share a small thought on the matter and how Paint.NET handles this. I can see now how this would definitely break Ctrl+F currently as I mentioned above, but what I had assumed is that Paint.NET would have handled this in a slightly different way that would have enabled the behavior ReMake and I desire(d) without breaking the repeat option:

 

For the moment, lets pretend that this is older Paint.NET and there is no effect preview. When you select the effect in the menu for the 2nd, 3rd, etc. time the program pulls the previous parameters from the appropriate tokens to populate the UI controls and then runs the effect when you press OK. Pressing Ctrl+F achieves the same as it checks the same tokens and then applies the effect with those parameters. What I'm suggesting is that if this new flag that is exposed to the IndirectUI is set to false (or whatever the default would be), this behavior stays the same, but if true, the parameters within the UI will be reinitialized to the specified defaults; however apply this to the UI only and always retain the previously applied settings in a separate token or some other kind of memory, having the Ctrl+F repeat function draw from those values instead. This way, the UI in the effect window has the option of showing the values applied in the previous effect usage OR the defaults depending on the wishes of the plug-in developer, but the Ctrl+F function isn't broken. I can't imagine that this would change things too much at all and would simply add a KB or two of ram usage and just require some small changes in references for the effect window and repeat option related functions. Now, this would be a tad dicey when you take into account the effect previews, except all that would need to be done is change the preview so that it uses the parameters specified in the UI as well instead of the parameters stored in the previous use token. Only have the token get updated when the user actually commits by pressing the OK button. This way if they hit cancel then the token hasn't been changed and hitting repeat later will still result in the effect being applied with the previous parameters.

 

I guess what I'm saying is, if you separate the parameter storage so that you have a dedicated token for the repeat option that only is updated when the user hits the OK button on an effect, not pulled from the plug-ins UI initialization routines and therefore not overwritten every time the user changes the primary color in this usage example, you would be able to maintain the repeat option's current behavior while adding the option for plug-in developers to reinitialize the values shown in the UI of their plugin (and there only) whenever the window for their effect is created. Essentially, keep the UI to itself is what I'm saying. I do understand this may have some implications on the programs Undo functionality that I haven't touched on, but I can't see that being too bad to handle either unless I'm being dumb and missing something.

 

Anyone that helps develop Paint.NET have any thoughts on this matter, whether it be feasibility or potential issues? Or does anyone else find this feature to be useful? Believe me I could overlooking something huge here and I also don't know how a lot of the programs functionality is handled behind the scenes, but from what I understand within this scope at least I feel like this could be a relatively simple change that would enable a tad more flexibility in the IndirectUI.

[toe_head2001]

I think that would just make it unnecessarily complicated. I think the solution that BoltBait demonstrated in the second post works sufficiently.

Edited July 23, 2018 by toe_head2001

[oblivioncth]

On 7/22/2018 at 10:05 PM, toe_head2001 said:

I think that would just make it unnecessarily complicated. I think the solution that BoltBait demonstrated in the second post works sufficiently.

 

Imo this wouldn't make it anymore complicated for a plugin developer, though I can understand it does make the code a little more complicated. Perhaps my situation is just a bit specific and what I want wouldn't be helpful that often but: BoltBaits suggestion is what I do in my plugin now to get around this; however, my plugin largely has to do with doing HSL adjustments to match colors with its primary usage being to select the color you want to change as the primary color and the color you want to change to as the secondary color. Because of this I feel like it makes much more sense to simply have 2 color pickers on my dialog that always default to the primary and secondary colors when its opened so that they can still be tweaked if needed but often will simply act as a reminder on what you're about to change and make the use of the plugin more intuitive, also avoiding the need of an additional dropdown box or radio group. Yes you can see the primary and secondary colors in the color window while using the plugin, but the window is faded and information that is critical to using the plugin correctly is then kind of just in the back out of focus instead of prominently being displayed directly.

 

I just found it strange that Paint.NET doesnt litterally just repeat an effect with the exact parameters used before when using Ctrl+F and instead does grab these parameters from the previously edited token, but does so by repeating the effects UI initilaization portion of its code so that what your options for what the user sees in the UI and what is actually in the "history" token are one in the same and inseparable, as this is not how I would have done it personally. Though again this is just my opinion. Perhaps many people would prefer the current behavior despite it not being how I imagined one would use this plugin.