UDL for DXL (C LIke) Number processing issues.
-
@swegmike
I’ve been working on my DXL autocomplete xml file and have been able to get it to pass the XML pluggin validation. However, when I try to save it, I get a popup as shown below regardless if I run the “Convert to UTF-8” or “convert to ANSI” even though the first line in the xml file specifies UTF-8.Am I really missing a DTD although I have NPP 8.4.7 now?
-
@swegmike ,
Good question. It looks legitimate, however, my Autocompletion file is encoding 1252 for the Windows standard, unless that’s changed by NPP. If I had to guess, perhaps the XML tools are what’s flagging it and doesn’t recognize it?It could also be a typo or other syntax violation later that doesn’t have a closing match or some such that is misplacing the error for you. Mind you, I’m not an expert, but if the tool is making the warning, it’s not NPP I don’t suspect. In my functionList.xml file, even though my file works, it gives an error ‘suspicion’ in my regex for the comment characters…so I don’t put a lot of stock in errors always showing where they are being where they really are. :) Sometimes, it’s elsewhere, but it’s easier for it to flag it somewhere else. ::shrug::.
-
The select file dialog is from the xml validation process.
I assume theenable auto validationfrom the xml menu has been checked. -
@Ekopalypse Thanks. that was the cause of the problem.
I think its strange that it would do this when trying to save the xml to a file since one may save a file based on partial editing or if it has bugs or is good for a later time. Moreover, one should use the xml pluggin to run the xml check manually to verify semantics/syntax at the time one wants the xml file being saved to be good- like I was doing. I’m wondering why the dtd/xsd error doesn’t occur when the manul xml verification in the pluggin is done vs. the auto validation checkbox functionality?
Although the xml pluggin finds alot of errors for a given xml start/end tag block i.e. <KeyWord… ,</KeyWord> it doesn’t always find the real cause of the error between them. i.e. Param misspelling etc. as Parm.
A big issue I had was after fixing all bugs in the xml, it was still flagging </AutoComplete> with an error inferring something between the start of it and this end tag had an issue. In the end when this happens, the cause was bad syntax for </KeyWord> such as no < or / before KeyWord or this being spelled as “Keyword”. A pain to find since I have 1500 KeyWord statements and it doesn’t colorize nor find the error other than stating </AutoComplete> as the error. To speed up the process of finding the issue, I had to do conquer and divide. That is take the first half and delete the rest and see if it passes, then continue this in halves to narrow down the region of my tags to locate which KeyWord was the cause…:(
-
@swegmike
Of the 1500 keywords I have this amounts to about 9100 lines of xml to scan thru for just one or more misspelled tags. In this case </KeyWord>I tried to see if online xmlvalidators are better at pointing to the exact line. However, they aren’t and just give me the </AutoComplete> error too.
Since there is no NPP autocomplete DTD/XSD defined, NPP can’t find the mispelled keyword mismatched tag structure directly from what I understand but only the syntax. I think a DTD is needed for NPP for this purpose.My xml data is in an Excel worksheet with other start/end autocomplete info. Thus worksheet macros concatenating the autocomplete header, with my xml data that is in the Overload/Param data tags and then with the autocomplete/NotepadPlus end tags to an xml merged worksheet that is then put in NPP after a little editing to remove the double quotes that MSoft adds upon copy/paste to MSofts notepad before placing in NPP. Then the double \r\n are removed for cleanup.
But I can narrow down the problem faster in Excel by filtering the xml column data for “doesn’t contain” </KeyWord> and it immediately pops out where the error(s) is at. Then I just scroll to keyword name that is in this cell that has the misspelled keyword tag. To reduce having to do this step after finding out within NPP; I’ll need to get in the habit to do this before copying everything via MSoft notepad to NPP to do the xml check there. -
I’m trying to format my autocomplete content so that when displayed as a hint, it shows various formatting such as bold, italic, underline, different font styles/sizes, hyperlinks etc.
However, entering <b>,</b> , <i>,</i>, <u>,</u> <h>,</h> into the xml strings for the return value, parameters or descriptions don’t work since it thinks its an xml error. Hyperlinks to external websites within the description or to the local harddrive for return values, function name/parameters and descriptions would also be useful since a user could pull up more detail or example programs that are extracted for the language reference manual since I can’t get everything into the function keywords string attributes in the autocomplete file.
I haven’t tried the CDATA string stuff to see if this works based on google for fonts etc. It appears that the “hint” first parameter may have a slight color change for only the first parameter as builtin to NPP, which I can’t control.Eventually, I’d like to add text colors too.
I have been experimenting with other xml markup besides the default ampersand, gt/lt , apos, quote names i.e. & . However, there are other names such as • that aren’t understood. However, if I enter the unicode value for other symbols such as this as • or newline the hint will show the symbol. Testing out other common symbols used for bulleted lists such as circles, diamonds, boxes both filled/unfilled seem to work. Even the copyright symbol as © or section § etc. However, picking a symbol for use based on the wikipedias unicode table listing is a mixed bag. It appears that NPP is more HTML 4.0 or earlier compliant but not HTML 5.0 although some symbols such as the checkmark ✓ will be displayed even though wikipedia says its HTML 5.0. -maybe a typo in wikipedia…
One of the things with the autocomplete xml file is that the description field may need to be a big paragraph. Using the newline unicode value helps to format it vs relying on the carriage return that was in the original text. I think in both cases this can be a big maintenance issue to keep the big paragraph text formatted so that it utilizes the display area efficiently and also based on a users screen resolution setting. There is no way to have NPP’s autocomplete automatically format a paragraph to fit the screen size/resolution to minimize the formatting like a regular text editor such as Word would do.
Eventually, one could take the completed autocomplete xml file and maybe have some tool use it to create a pdf or webpage user manual via xlst or something similar. More investigation is needed to see if this is possible…
Thus, is NPP only HTML 4.0 compliant and not v5.0? What about xHMTL or compatible with math symbols? How to get formatting such as bold/italic, fonts and hyperlinks to work in the autocomplete files?
-
is NPP only HTML 4.0 compliant and not v5.0? What about xHMTL or compatible with math symbols?
Config files like the autocompletion definitions are XML, not HTML, so of course they won’t be HTML5 compatible. XML recognizes numeric/hex entities and the 5 or so standard named entities – I believe the Wikipedia article on XML lists that small list (
on my phone, so I’m not going to look it up for you: edit: confirmed = there are 5 pre-defined entities in XML). So other than that handful, use the numeric/hex entities in the XML definition files.How to get formatting such as bold/italic, fonts and hyperlinks to work in the autocomplete files?
As far as the autocompletion hints, they aren’t designed for fancy rendering so adding bold or other such formatting to the hints that show up is not an intended feature for those hint boxes
There is no way to have NPP’s autocomplete automatically format a paragraph to fit the screen size/resolution to minimize the formatting like a regular text editor such as Word would do.
And please disabuse yourself of the comparison between MS Word and Notepad++. Word is a word processor, not a text editor, despite your assertion. They are two different types of applications.
-
@PeterJones said in UDL for DXL (C LIke) Number processing issues.:
XML recognizes numeric/hex entities
Actually, if you look at the discussion here, it appears that Notepad++'s parsing of the XML might have difficulty with the decimal numeric entities, so it seems more reliable to just use the hex entities (the ones that start with
&#xthen have 1 or more hexadecimal nibbles, followed by the;)
