Comments (7)
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:
- In Notepad++, navigate to menu: Settings » Import » Import Plugins... and import the dll file extracted from the zip file.
- OR, Extract the
FWDataviz.dll
file into the<NPP_Plugins_folder>/FWDataviz
folder to overwrite the existing DLL therein. - PLUS, Extract the
default_FieldTypes.ini
file into the<NPP_Plugins_folder>/FWDataviz
folder. This step will then automatically copy this file renamed asFieldTypes.ini
into theConfig/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.
Related Issues (20)
- NPP Plugin Version HOT 2
- No colorization after switching to 64 bit HOT 4
- "FWDataViz.dll is not compatible with the current version of Notepad++" message in Notepad++ HOT 45
- Desire for a Variable Width Data Viz. HOT 4
- FWDataViz will crash Notepad++ when scrolling beyond last line
- Crash when clicking the Plus or Minus buttons on the filled line items after a Data Extraction
- Manually set selections of File Type and Visualizer Theme are being lost when returning to the same doc after briefly switching to a different doc in NPP HOT 1
- Folding feature request HOT 13
- Small feature request HOT 1
- Feature request: Sequence Numbers in the 'Jump to Field' dropdown list HOT 6
- Continuous Flicker with Show Calltip option when Word Wrap is enabled HOT 1
- No File Type visible in FWDataViz panel initially HOT 2
- Clarification for: Jumping to next field gets to one character before next field HOT 2
- Trim Fields for Data Extraction HOT 2
- Creating new fold structures crashes Notepad++ HOT 1
- Visualizer Styles don't work on large files HOT 3
- Bug in column navigation (arrows) HOT 3
- FWDataViz is visualizing a fixed-width file only when the plugin is the topmost in a stack of panels
- 'Auto-Detect File Type' crashes Notepad++ when a file with a line having more than 32767 chars is opened
- Porting to VS Code HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from fwdataviz.