Don't use a forward-slash ( / ):
{ Example code not included in quote }
Hello:
This is just a brief comment to clarify that a "Back Slash" (
\ ) can only be used for certain types of coding in Windows.
It is important to distinguish a "Back Slash" (
\ ) from a standard "
Slash" aka "
Forward Slash" character: (
/ ).
en.wikipedia.org
While Windows OS is technically capable of 'tolerating' use of both
\ and
/ characters in folder and file paths:
https://en.wikipedia.org/wiki/Path_(computing)
...a "Back Slash" (
\ ) may not be tolerated in other types of coding for most Windows applications, and is regarded as reserved for special purposes utilized by programming languages such as
C,
Perl,
PHP,
Python,
Unix scripting languages, and many file formats such as
JSON.
FYI: Use of a "Back Slash" ( \ ) instead of a "
Slash" aka "
Forward Slash" character (
/ ) in MSFS-2020
*.JSON files may
'Ux up / 'Nix things'.
Conversely, use of a "
Slash" aka "
Forward Slash" character (
/ ) in Windows Paths / Windows applications ...may also
'Ux up / 'Nix things'.
https://www.google.com/search?q=site:www.fsdeveloper.com+GaryGB+"slash"+path+DOS+CMD&source=hp&ei=qRn4YIuBLPa-0PEP8qGm6Ak&iflsig=AINFCbYAAAAAYPgnuULytJqLbSfb9VfOYZ4ued7ZJOcL&oq=site:www.fsdeveloper.com+GaryGB+"slash"+path+DOS+CMD&gs_lcp=Cgdnd3Mtd2l6EAM6CwguELEDEIMBEJMCOggIABCxAxCDAToCCAA6CwguELEDEMcBEKMCOgUIABCxAzoICC4QxwEQrwE6DgguELEDEMcBEK8BEJMCOgUILhCxAzoCCC46CAguELEDEIMBOgsILhDHARCvARCTAjoOCC4QsQMQgwEQxwEQowI6DgguELEDEMcBEKMCEJMCOgQIABAKUJgMWMOyAWCLtwFoAHAAeACAAcsBiAHbGZIBBjI1LjguMZgBAKABAaABAqoBB2d3cy13aXo&sclient=gws-wiz&ved=0ahUKEwjL-desm_TxAhV2HzQIHfKQCZ0Q4dUDCAg&uact=5
[
EDITED]
en.wikipedia.org
"
XML
XML has been used to describe structured data and to serialize objects. Various XML-based protocols exist to represent the same kind of data structures as JSON for the same kind of data interchange purposes. Data can be encoded in XML in several ways. The most expansive form using tag pairs results in a much larger representation than
JSON, but if data is stored in attributes and 'short tag' form where the closing tag is replaced with />, the representation is often about the same size as
JSON or just a little larger. However, an XML attribute can only have a
single value and each attribute can appear at most
once on each element.
XML separates "data" from "metadata" (via the use of elements and attributes), while
JSON does
not have such a concept.
Another key difference is the addressing of values.
JSON has objects with a simple "key" to "value" mapping, whereas in XML addressing happens on "nodes", which all receive a unique ID via the XML processor. Additionally, the XML standard defines a common attribute xml:id, that can be used by the user, to set an ID explicitly.
XML tag names
cannot contain any of the characters
!"#$%&'()*+,/;<=>?@[\]^`{|}~,
nor a
space character, and
cannot begin with
-,
.,
or a
numeric digit, whereas
JSON keys can (even if quotation mark and backslash must be escaped).
XML values are strings of
characters, with no built-in
type safety. XML has the concept of
schema, that permits strong typing, user-defined types, predefined tags, and formal structure, allowing for formal validation of an XML stream.
JSON has strong typing built-in, and has a similar schema concept in
JSON Schema.
XML supports comments, while
JSON does
not."
en.wikipedia.org
"
Syntactical correctness and error-handling
Main article:
Well-formed document
The XML specification defines an XML document as a
well-formed text, meaning that it satisfies a list of syntax rules provided in the specification. Some key points in the fairly lengthy list include:
- The document contains only properly encoded legal Unicode characters.
- None of the special syntax characters such as < and & appear except when performing their markup-delineation roles.
- The start-tag, end-tag, and empty-element tag that delimit elements are correctly nested, with none missing and none overlapping.
- Tag names are case-sensitive; the start-tag and end-tag must match exactly.
- Tag names cannot contain any of the characters !"#$%&'()*+,/;<=>?@[\]^`{|}~, nor a space character, and cannot begin with "-", ".", or a numeric digit.
- A single root element contains all the other elements."
PS: Windows Path length and/or long folder and file names may also be a source of complications to successful use of the MSFS-2020 SDK:
en.wikipedia.org
https://www.google.com/search?client=firefox-b-1-d&q=MSFS+path+length+long+file+names
Starting in Windows 10, version 1607, MAX_PATH limitations have been removed from many common Win32 file and directory functions. However, your app must opt-in to support the new behavior.
docs.microsoft.com
One of our customers habitually use very long path names (several nested folders, with long names) and we routinely encounter "user education issues" in order to shorten the path to less than 260
serverfault.com
https://blog.codinghorror.com/filesystem-paths-how-long-is-too-long/
"
I think 260 characters of path is more than enough rope to hang ourselves with. If you're running into path length limitations, the real problem isn't the operating system, or even the computers. The problem is the
deep, dark pit of hierarchies the human beings have dug themselves into."
NOTE: While one may extend Windows OS 10 et seq.
Path length limit (for "
Fully Qualified File Names") of
~235+12 or
~239+11 characters (...but regardless, in actuality
NOT 255, 256, or 260 characters long !),
...
can MSFS-2020 and/or MSFS-2020 SDK actually handle Windows Paths this long ? 
Sometimes, the obvious is over looked because error messages often do not allude to the actual problem being encountered. For example, the online document management service eRoom presenting the fo…
windowsexplored.com
In Windows 10 Home is there a way of stopping this from happening?
answers.microsoft.com
https://knowledge.autodesk.com/supp...th-limitation-MAX-PATH-is-256-characters.html
https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file?redirectedfrom=MSDN
https://mspoweruser.com/ntfs-260-character-windows-10/
BTW: If MS so urgently wants to 'snoop' on end users of the OS and MSFS, presumably it would want to do so only when a user is 'logged on' to Windows.
One "should" always have full file / folder permissions in Windows' Security sub-system when logged onto Windows with access to the Network via UNC.
Thus we could in theory always use UNC names as a fully-compatible way to 'work-around' Path limitations in Windows ...but perhaps not for all "Apps" ?
https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file
"
Naming Conventions
The following fundamental rules enable applications to create and process valid names for files and directories, regardless of the file system:
- Use a period to separate the base file name from the extension in the name of a directory or file.
- Use a backslash (\) to separate the components of a path. The backslash divides the file name from the path to it, and one directory name from another directory name in a path. You cannot use a backslash in the name for the actual file or directory because it is a reserved character that separates the names into components.
- Use a backslash as required as part of volume names, for example, the "C:\" in "C:\path\file" or the "\\server\share" in "\\server\share\path\file" for Universal Naming Convention ( UNC ) names. For more information about UNC names, see the Maximum Path Length Limitation section.
- Do not assume case sensitivity. For example, consider the names OSCAR, Oscar, and oscar to be the same, even though some file systems (such as a POSIX-compliant file system) may consider them as different. Note that NTFS supports POSIX semantics for case sensitivity but this is not the default behavior. For more information, see CreateFile.
- Volume designators (drive letters) are similarly case-insensitive. For example, "D:\" and "d:\" refer to the same volume.
- Use any character in the current code page for a name, including Unicode characters and characters in the extended character set (128–255), exceptfor the following:
- The following reserved characters:
- < (less than)
- > (greater than)
- : (colon)
- " (double quote)
- / (forward slash)
- \ (backslash)
- | (vertical bar or pipe)
- ? (question mark)
- * (asterisk)
- Integer value zero, sometimes referred to as the ASCII NUL character.
- Characters whose integer representations are in the range from 1 through 31, except for alternate data streams where these characters are allowed. For more information about file streams, see File Streams.
- Any other character that the target file system does not allow.
- Use a period as a directory component in a path to represent the current directory, for example ".\temp.txt". For more information, see Paths.
- Use two consecutive periods (..) as a directory component in a path to represent the parent of the current directory, for example "..\temp.txt". For more information, see Paths.
- Do not use the following reserved (OS device) names for the name of a file:
CON, PRN, AUX, NUL, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, and LPT9. Also avoid these names followed immediately by an extension; for example, NUL.txt is not recommended. For more information, see Namespaces.
- Do not end a file or directory name with a space or a period. Although the underlying file system may support such names, the Windows shell and user interface does not. However, it is acceptable to specify a period as the first character of a name. For example, ".temp"."
Can MSFS-2020 and/or MSFS-2020 SDK actually handle Windows UNC file / folder paths ?
Might this complexity result from Asobo attempting to make end users do their work for them to pre-configure content for a VFS / 'AXOS' input mechanism ?
https://www.fsdeveloper.com/forum/threads/rotating-beacon-light-tower.453047/post-886433
also has this error message I get the same thing.
www.fsdeveloper.com
IMHO, this merits quoting ...
again:
"The problem is the
deep, dark pit of hierarchies the human beings have dug themselves into":
I somehow doubt this is what Joyce Kilmer was thinking of when he wrote the poem Trees [http://www.bartleby.com/104/119.html]: > I think that I shall never see A poem lovely as a tree. It's unfortunate that the treeview is one of the standard widgets in a
blog.codinghorror.com
"It's unfortunate that the treeview is one of the standard widgets in a usability designer's toolkit, because
trees aren't usable. They're a pain in the ass. They may be necessary for developers who are forced to work in the strict, rigid world of software development, but they are unnatural, restrictive, and just plain unnecessary for average users."
[
END_EDIT]
GaryGB
