CodeLab v6.12 for Paint.NET 5.0.12 (Updated February 11, 2024)

[Red ochre]

 

I discovered this can be done by the following call:

configUI.SetPropertyControlValue(PropertyNames.Amount1, ControlInfoPropertyNames.DecimalPlaces, 3);

That works! Many thanks, very useful.

[toe_head2001]

There are two pieces of code that CodeLab generates which I have questions about.
 
1) Why is 'unsafe' needed here? or is just there so we can put unsafe code in Render?

protected override unsafe void OnRender(Rectangle[] rois, int startIndex, int length)
{
	if (length == 0) return;
	for (int i = startIndex; i < startIndex + length; ++i)
	{
		Render(DstArgs.Surface, SrcArgs.Surface, rois[i]);
	}
}

void Render(Surface dst, Surface src, Rectangle rect)
{
}

 
2) What does this line in OnSetRenderInfo do? This question is probably due to some ignorance of C# I have.

base.OnSetRenderInfo(newToken, dstArgs, srcArgs);

Thanks.

[null54]

1) Why is 'unsafe' needed here? or is just there so we can put unsafe code in Render?

Codelab has templates that use pointers.

 

2) What does this line in OnSetRenderInfo do? This question is probably due to some ignorance of C# I have.

It is used to perform any setup that the filter may require before Render is called.

The FurBlur source code in this post uses it to render the effect to a second surface which avoids the ROI problems with Render being called multiple times.

[Ego Eram Reputo]

Expanding on the Unsafe keyword;

Pointers can read past your virtual screen bounds (or whatever) into memory used for other stuff. If you start writing into these locations things are going to break quickly.

The Unsafe keyword let's you know you're close-to-the-edge and should be very careful. It is also an acknowledgement that you understand the risks

[toe_head2001]

It is used to perform any setup that the filter may require before Render is called.

The FurBlur source code in this post uses it to render the effect to a second surface which avoids the ROI problems with Render being called multiple times.

I appreciate you taking the time to respond, but I already know what OnSetRenderInfo is used for as a whole. I specifically would like to know what the following line does.

base.OnSetRenderInfo(newToken, dstArgs, srcArgs);

Here it is in context.

protected override void OnSetRenderInfo(PropertyBasedEffectConfigToken newToken, RenderArgs dstArgs, RenderArgs srcArgs)
{
    Amount1 = newToken.GetProperty<DoubleProperty>(PropertyNames.Amount1).Value;

    base.OnSetRenderInfo(newToken, dstArgs, srcArgs);
}

[BoltBait]

Whenever you override a base class function, it is a good idea to call the origional function you are overriding. That way, whatever your code is doing will be in addition to what was designed in the base class.

I'm not exactly sure what the base class is doing here, it could be nothing.

[toe_head2001]

Whenever you override a base class function, it is a good idea to call the original function you are overriding. That way, whatever your code is doing will be in addition to what was designed in the base class.

 

Ah, that makes sense. Thank you.

 

I'm not exactly sure what the base class is doing here, it could be nothing.

 

That is my suspension as well, because I removed that line of code and everything in my effect still worked. I'll leave it in though, just in case.

[BoltBait]

A while ago I said:

 

I have a suggestion. I think the double-vector position control should be changed to three decimal places instead of the current two. As it is, there are only 200 or so possible values, which means for most reasonable window sizes, the position cannot be placed within a pixel. Even with three decimal places, positioning for large windows wouldn't be within a  single pixel, but at least it would usually be fine enough to be useful. I didn't use the position control in my Texture Shader plugin for that very reason.

 

I discovered this can be done by the following call:

configUI.SetPropertyControlValue(PropertyNames.Amount1, ControlInfoPropertyNames.DecimalPlaces, 3);

Great idea. I think the next rev of CodeLab will automatically put this in for all Double Vector controls.

Now, the question is, should I put this in for all floating point controls, like the decimal slider and roll control.

[Ego Eram Reputo]

I don't see the need for a slider to have that level of precision. Ditto the roll control. However it won't hurt at all, so why not?

[MJW]

That's a hard question. Because the Double Vector pretty much always represents the image range as -1 to 1, three places (or even four) makes sense. The Double Slider can represent lots of things, with lots of different ranges. If the range is 0 to 1000, it seldom makes sense to have three places of precision, and using the up-down control becomes more difficult for small adjustments, because the steps are too small. But many times when the range is 0 to 1, I wish I had more precision. I suppose the precision could depend on the range, with enough precision to ensure at least a thousand steps. What I'd really like -- though it might be difficult to implement -- is the ability to specify the precision, perhaps be adding control names like DoubleSliderControl1, DoubleSliderControl2, DoubleSliderControl3, where the digit would specify the number of places, with DoubleSliderControl having the default precision. That might present problems for the UI Designer, adding some ugliness of a bunch of extra controls, or requiring a new field for the decimal place specification. Because the smallest range of the roll controls is 0-90, allowing 9001 steps for two decimal places, I don't think it probably needs three places.
 
EDIT: I think the up-down increments for the roll control are too large. Currently, each click increments or decrements by 1. For Double Sliders, it's 0.01. I determined that the increments can be set by:

 configUI.SetPropertyControlValue(PropertyNames.Roll, ControlInfoPropertyNames.UpDownIncrementX, 0.01);
 configUI.SetPropertyControlValue(PropertyNames.Roll, ControlInfoPropertyNames.UpDownIncrementY, 0.05);
 configUI.SetPropertyControlValue(PropertyNames.Roll, ControlInfoPropertyNames.UpDownIncrementZ, 0.10);

That was just a test to try the three different increments. An increment of 0.01 for all three seems best to me.

Edited November 27, 2015 by MJW

[toe_head2001]

I don't see the need for a slider to have that level of precision...

 

I added a third decimal place onto the Scale control of my Jigsaw Puzzle plugin, and it made a significant difference.

Edited November 26, 2015 by toe_head2001

[MJW]

I agree with toe_head2001. Many times for scale and shift type controls, two places isn't enough to make a singe-step change nearly imperceptible, which it needs to be for the user to achieve a particular result.

[BoltBait]

Here is my proposal:

DoubleVector control, always add 3 decimal places

AngleControl, always add 3 decimal places

DoubleSlider control, if the upper bounds is < 1000 add 3 decimal places

RollControl, always add 3 decimal places and adjust the steps (posted above)

OK?

[toe_head2001]

I vote OK. I think those are good defaults that will fit the majority of use cases.

[BoltBait]

Here is my proposal:

DoubleVector control, always add 3 decimal places

AngleControl, always add 3 decimal places

DoubleSlider control, if the upper bounds is < 1000 add 3 decimal places

RollControl, always add 3 decimal places and adjust the steps (posted above)

OK?

The angle control wouldn't take the 3 decimal places. Could this be a bug in paint.net? Only Rick knows for sure.

[MJW]

The UpDown increment also doesn't seem to work. I actually think 2 places is enough for both the Angle Chooser and the Roll control. One hundredth of a degree is pretty small. I wish the UpDown increment could be made smaller. The only way to enter more exact angles is either hit or miss with the slider or typing it in.

 

One thing that bugs me about all the controls is how they use (or don't use), the small and large slider increment value. I would think moving the slider should only change the control value in multiples of those values, so if one is 0.05 and the other is 0.25, all the slider movements would change the value by multiples of 0.05. Instead, the sliders seem to change the values in a rather haphazard way, which makes positioning to even values more difficult.

[BoltBait]

CodeLab 2.10 Released

This is only for Paint.NET 4.0.6+!

Changes:

▪ Double Vector control, Double Slider control, and Roll control now have 3 decimal places of precision

▪ New options added to File > New template screen

▪ Scripts can now specify the version number:

// Version: 3.14

or

// Version: 3,14

 

 

Grab the CodeLab DLL here:

http://www.boltbait.com/pdn/CodeLab/

[Ego Eram Reputo]

Version option is very welcome. Thank you BoltBait.

[ReMake]

CodeLab 2.10 in Russian

You can find the new version of CodeLab in Russian here.
Вы можете найти новую версию CodeLab на русском языке здесь.

[toe_head2001]

I was playing with ScintillaNET this morning, and decided to try using it in CodeLab for fun. BoltBait, you should look into this. It's highly configurable. It's like having Notepad++ (which uses Scintilla) inside CodeLab.

 

Although the IntelliSense stuff might be difficult, but I didn't look at how it's currently being done in CodeLab, so maybe not difficult to integrate the current implementation into the Scintilla control...

Edit: I took a look at the code for the custom IntelliSense, and I don't see why it wouldn't work.

 

Advantages over using a RichTextBox:

-Code folding

-Show white space

-Line numbers (adjusted for the hidden prepended lines of code?)

-Undo!

-Word wrap

-Autocomplete (things not covered by the IntelliSense)

-Current Line indicator

-all the other features that Scintilla has

-Discard all the code hacks to get RichTextBox working as a code editor
 

Edited February 5, 2016 by toe_head2001

[pyrochild]

Bug: If you make a change to the script, then click OK before CodeLab rebuilds the effect, the change will not be applied.

(Yeah, yeah, "just wait the 3 seconds, pyro")

[BoltBait]

Thanks guys!

I'll look at both issues over the weekend.

[BoltBait]

CodeLab 2.11 Released

This is only for Paint.NET 4.0.9+!

Changes:

▪ Bug fixes

▪ "Hack" font added to supported fonts list. Download Hack Font.

▪ toe_head2001 replaced the RTF editor control with the ScintillaNET editor component.

This is awesome because it is basically the same editor you'd find in Notepad++. All of the silly patches I had to put in to make an RTF control work for syntax highlighting have been removed.

We now have proper unlimited UNDO and REDO commands in the editor. The editor now includes lots of other features of Notepad++ including brace matching, block folding, show white space, word wrap, and current line highlighting.

 

 

Grab the CodeLab DLL here:

http://www.boltbait.com/pdn/CodeLab/

[ReMake]

CodeLab 2.11 in Russian

You can find the new version of CodeLab in Russian here.
Вы можете найти новую версию CodeLab на русском языке здесь.

[pyrochild]

Trying to build to DLL always gives me the error message:

---------------------------

Build Error

---------------------------

Before you can save as a DLL you must first save your source file using the File > Save as... menu.

---------------------------

OK

---------------------------