More control over coloring about fwdataviz HOT 7 CLOSED

Thank you, @trybowski.

The first solution that springs to my mind is inspired by the variable type-annotation syntax of TypeScript. For example:

var name:string = "Meaning of Life"; 
var answer:number = 42

Similarly, I propose this solution to see if it is worth pursuing: In the File Type Metadata Editor, we could have the user-defined field types to optionally follow the individual field labels after the colon (:) separator. For example, we could have these field labels:

Invoice Number
Item Name
Price:AMOUNT_DECIMAL
Quantity:WHOLE_NUMBER
Total Price:AMOUNT_DECIMAL
Transaction Date:ISO_DATE
Posting Date:US_DATE
Shipping Status

Note: The first two and the last fields in the above list have not been specified with a field type to underscore that field types are going to stay optional.

To go along with these generic field types, we could have style definitions for them in a new INI file, say, FieldTypes.ini. The style definitions will utilize the same BFBI (Background, Foreground, Bold, Italics) syntax that we are already using in the Themes.ini file.

There will be loose coupling between the two ini files: Visualizer.ini and FieldTypes.ini. So, if a field type has been used after a field label in Visualizer.ini and not specified in FieldTypes.ini, or been mis-typed in either file, the visualizer will just use the file type or record type theme coloring sequence without skipping a beat.

Also, the Cursor Position Data field could only display the part of the field label preceding the colon, and not the optional field type. Or should it?

Finally, I could probably give you a working solution sooner if I didn't have to implement a graphical interface to define styling definitions for the generic field types. I mean something similar to the Themes Editor. Since this feature is meant to be used by power users like you, I assume you could manually type in those BFBI definitions for your custom field types with a text editor like NPP. You could still use the Themes Editor to define matching styles in a dummy theme and copy the BFBI values over to FieldTypes.ini.

So, let me know what you think.

from fwdataviz.

Hi, thanks for your quick response.
Yes, I believe your proposal would work. You went a little bit further than I did, because I wanted to assign color directly to field labels, and you propose to use an additional entity: “field type”. This opens additional possibilities, such as: a field type definition could also hold information about allowed values (such as numeric, string etc) and this could be used to perform some simple validation. But let's not get ahead of ourselves.

Regarding Cursor Position Data — I don't know. Suit yourself.
I can easily work without the front-end to define colors :)

THANKS!

from fwdataviz.

@trybowski , I have a build that includes the core enhancement. If you wish to try it out now, use the attached builds below.

Now that the core of the enhancement is done, a graphical interface to handle the Field Style Definitions seems to be within easy reach. So, I will implement this new dialog and then plan on a proper release.

In the meanwhile, you could try this build with direct manual edits to the Config/FWDataViz/FieldTypes.ini file. You could define your own custom generic fields. See the default_FieldTypes.ini file included in the build zip archive.

[Styles]
DATE=703050 C8C8C8 10

Here, DATE is the generic field type. The field type is not case sensitive. It can also contain spaces.

After you define your own generic field types, you can start referencing them in the File Type Metadata Editor's Field Labels box. For example:

Transaction Date:date
Posting Date : DaTe
Shipping Date   :   dAtE

Note: In the sample usage, variations in the spacing around the colon and the casing of the field type are intentional, done so to illustrate that spaces and case sensitivity do not matter.

DLL-only manual upgrade of a previously installed version of the plugin

Download the zip file version to match your Notepad++ bitness. Then, either:

1. In Notepad++, navigate to menu: Settings » Import » Import Plugins... and import the dll file extracted from the zip file.
2. OR, Extract the FWDataviz.dll file into the <NPP_Plugins_folder>/FWDataviz folder to overwrite the existing DLL therein.
3. PLUS, Extract the default_FieldTypes.ini file into the <NPP_Plugins_folder>/FWDataviz folder. This step will then automatically copy this file renamed as FieldTypes.ini into the Config/FWDataViz folder.

64-bit build:
FWDataViz_x64.zip

32-bit build:
FWDataViz_x86.zip

from fwdataviz.

OK, I tested and... it works but not entirely correctly.

• My file as a base theme uses “Grey” which is basically just two shades of grey.
• I have two types of lines — those which have a non-zero monetary value (on green and blue background) and those which only have zeroes there. The grey colors nicely alternate between the lines — that's cleverly done!
• The colors of columns (of defined filetypes) in both line types should be the same. I want to differentiate the lines by bold and italic attributes only.

Sadly, last three field types are not associated in the second record type, which is marked on the below screenshot:

The field is recognized, it's just the color which is not applied (please note: the following two screenshots are based on a slightly altered config, where I don't use STORE_ALT type, and just use STORE for both record types):

But in another record type (FAR-zeroline) this field type definition works:

Here's the config which I used: Config_FieldTypes_Visualizer.zip

from fwdataviz.

I had failed to mention that I had set an internal limit of 25 Field Styles in the build. Thank you for providing your FieldTypes.ini file. As soon as I saw that you had defined 32 field styles, I could sense the source of your issue.

Let me clarify further. The Scintilla component which is at the core of NPP allows defining up to 255 style sets per document. Of these 255, the first 39 are reserved for internal use by Scintilla. This number is defined by the Scintilla constant STYLE_LASTPREDEFINED. Please refer to the code below, an extract from VisualizerPanel.h, as you read further.

constexpr int FW_STYLE_THEMES_START_INDEX{ STYLE_LASTPREDEFINED + 1 };
constexpr int FW_STYLE_THEMES_MAX_ITEMS{ 175 };
constexpr int FW_STYLE_FIELDS_START_INDEX{ FW_STYLE_THEMES_START_INDEX + FW_STYLE_THEMES_MAX_ITEMS };
constexpr int FW_STYLE_FIELDS_MAX_INDEX{ FW_STYLE_FIELDS_START_INDEX + 25 };

Prior to this enhancement, I had FW_STYLE_THEMES_MAX_ITEMS defined to a max value of 200. I am always using style #40 for the EOL marker. Then the next 200 were meant for styles defined in all the themes that are actively used by a File Type, including any of its record-type theme overrides. That would be the block from #40 to #239. I was leaving alone the last 16 or so styles (from #240 to #255) just in case they were being used by NPP in some obscure feature that I don't use in NPP and may not be aware of.

When implementing this enhancement, I did not want to go beyond the block of styles that I had been using until now with no reported issues. Still, I had to make room for the new block of field styles somewhere within that range of 200. For lack of anything better, I decided to allocate a block of 25 within that block of 200, towards the upper end. Now, if you see the code above, I have redefined FW_STYLE_THEMES_MAX_ITEMS to 175 (down from its original value of 200) to make room for the 25 Field Styles.

But you have defined 32 field type styles in your file. I would guess all of these are in use for the file type you are testing it with. And, you were probably noticing fields beyond the 25th not being rendered in the document. So, I am providing you with a build wherein only 150 are allocated for the theme styles, and 50 are reserved for field styles. Try it out and let me know if that fully works as expected.

This build also includes the fix for issue #39 you have reported today.

64-bit build:
FWDataViz_x64.zip

32-bit build:
FWDataViz_x86.zip

from fwdataviz.

I've found another issue. When I turn off FWDataViz Panel, what's supposed to happen? Should the coloring disappear? Anyway, he theme-based colors disappear, but the field type-based colors sometimes reappear. Please see this: https://www.youtube.com/watch?v=4i61a-96JXk

from fwdataviz.

Thanks for noticing that. I have fixed it. The fixed builds are at the end of this post.

I delayed providing you the build since I was optimizing the plugin functionality further by allocating the available style slots flexibly and more efficiently. I realized that users who tend to use lot of theme-based styles would be using less of field-based styles, and vice versa. I will explain the optimization with an analogy.

Let's think of the range of 200 styles that the plugin uses as a metaphorical narrow, rectangular, 200-inch long cake. There are two 'worms' who get to share this same cake baked fresh everyday. On days when the theme-based worm is very hungry, the field-based worm is not at all hungry, and vice versa. So, it does not make much sense to divide the cake into the same, pre-determined, fixed portions on all days.

We can tell the theme-based worm to start from the left end and keep eating as much as it wants, while working its way in the rightward direction. And, tell the field-based worm that it can start from the right end and keep eating, while working its way in the leftward direction. The senior theme-based worm is allowed to eat the entire 200-inch cake, if necessary. But the junior field-based worm is allowed to eat only up to 164 inches, leaving a minimum of 36 inches for the senior.

When previously the junior worm was oriented to eat in the same direction as its senior, it was allowed to eat only 50 inches (and, a mere 25 inches prior to that). By reorienting the worm to eat in the opposite direction, it can now eat three-times as much on days when it gets very hungry. Thus, in all but ridiculously extreme use cases, both worms will be fully fed; and neither of the worms will stay partially fed while the other worm has uneaten left overs.

In view of this optimization, please test the build for any new issues or regressions. Appreciate your feedback.

64-bit build:
FWDataViz_x64.zip

32-bit build:
FWDataViz_x86.zip

from fwdataviz.