XmlDataProvider Source="pack://application:,,,/FinanceExplorer/Equity.xml" - xaml

Can someone explain the syntax in the source attribute here? What the heck is "pack:" and "application:" and why 3 commas? I couldn't find any decent desciptions.

Here's the MS documentation on the Pack URI Scheme
The three commas represents a XAML resource file that is located in the root of the local assembly's project folder.

The packageURI is actually a URI within a URI,so it is encoded by converting its forward
slashes into commas.
Therefore,the triple commas are actually encoded forward slashes.
Also you could replace something like
pack://application:,,,/logo.jpg
with this
/logo.jpg
The runtime will prefix the pack://application:,,,.

Related

How to pass feature file path with included spaces on command line via karate.options

On Windows systems, paths with included spaces are allowed. For our framework built on top of Karate, I would like to robustly handle such eventualities. But if there are spaces in the feature file path given to karate.options, Karate interprets the value as multiple paths, as this is by design.
So I've already tried enclosing the path with single and double quotes, as well as all possible pairs of parentheses. Unfortunately, none of these seem to work. Is there no syntax to express this intention?

PATHS: trailing backslash or not trailing backslash?

I've many VBA scripts and functions where I read a manually inserted (in Excel cell) local disk paths and I'm still confused about whether to normalize the inserted paths by adding or trimming the trailing backslash.
What do you use as the general standard? with or without the trailing backslash?
My confusion is fueled by the fact that for example ActiveWorkbook.path returns a path without trailing backslash while the CopyFile (FileSystemObject) method for the "Destination" parameter wants the trailing backslash otherwise it considers it as a file instead than a directory (and can give unexpected Permission denied errors)
The general idea is to always end a directory's name with a backslash. This is advised in the URL you mention, but there are quite some other situations as well (check my answer on a regularly occuring xcopy problem).
As mentioned: when you don't put a backslash, the question might arise "Is it a file or a directory?". Putting the backslash solves that question.
In top of that, while programming, regularly you might have following situation:
complete_filename = path + filename
Obviously, if you have forgotten to put the backslash at the end, this might cause problems (e.g. you don't want to create a file, called "C:\Tempoutput.txt" instead of "C:\Temp\output.txt", I presume? :-) )

wix: does INSTALLDIR always end in a slash?

I think the default dir gets a trailing slash.
But what if the user selects a different directory?
Is there a way for the INSTALLDIR to NOT have a trailing slash?
It's not that I want it to not have a trailing slash. I want to know if I can count on it, so that, for example,
[INSTALLDIR]Filter.dll
...will always resolve to a real, valid filesystem path.
Currently I use
[INSTALLDIR]\Filter.dll
and I get a double-slash in there. It's valid and resolves, but I'd like to eliminate the double slash.
thanks.
Windows Instaler directory table entries ( which become properties after costing ) are always formatted by MSI to contain a trailing backslash. Including extra slashes will not harm the resolution.
It is my understanding that Windows Installer will add a backslash to any Directory table entry. Therefore, yes, you can eliminate your slash and not worry about things breaking.
In fact, this has even prompted InstallShield to create a KB article describing how to REMOVE the backslash...
http://kb.flexerasoftware.com/selfservice/viewContent.do?externalID=Q106587

Pound sign (#) in filename causing error

I have a very simple file upload that allows users to upload PDF files. On another page I then reference those files through an anchor tag. However, it seems that when a user upload a file that contains the pound sign (#) it breaks the anchor tag. It doesn't cause any type of Coldfusion error, it just can't find the file. If I remove the #, it works just fine. I am sure there are a number of other characters that would have this same issue.
I've tried putting URLEncodedFormat() around the file name inside the anchor but that doesn't help. The only other thing I could think of was to rename the file each time it was uploaded and remove the "#" character (and any other "bad" character).
There has got to be an easier solution. Any ideas?
If you control the file upload code try validating the string with
IsValid("url",usersFileName) or
IsValid("regex",usersFileName,"[a-zA-Z0-9]")
Otherwise if you are comfortable with regex I would suggest something like the previous posters are commenting on
REReplace(usersfilename,"[^a-zA-Z0-9]","","ALL")
These samples assume you will add the ".pdf" and only allows letters and numbers. If you need underscores or the period it would look like this...
REReplace(usersfilename,"[^a-zA-Z0-9\._]","","ALL")
I am not a regex guru, if I have one of these wrong I am sure several will jump in and correct me :)
Pound signs are not legal within filenames on the web. They are used for in-page anchor targets:
<a name="target">
So if you have file#name.pdf, the browser is actually looking for the file "file" and the internal anchor "name.pdf".
Yes, you will have to rename your files on upload.
I can't comment yet,
but Kevink's solution is good unless you need to perserve what you're replacing.
We ran into an instance where we needed to rename the filename but the filename needed to be somewhat preserved (user requirement). Simply removing special characters wasn't an option. As a result we had to handle each replace individually, something like.
<cfset newName = replace(thisFile, "##", "(pound)", "All")>
<cfset newName = replace(newName , "&", "(amp)", "All")>
<cffile action="rename"source = "#ExpandPath("\uploads\#thisFolder#\#thisFile#")#" destination = "#newName#">
Probably you would have to replace # with ## to avoid this, I think this is caused because # is figured as Coldfusion keyword.

Configure apache to treat static resources with "?" character in filename

For various reasons, I have a bunch of static resources all with the following naming format:
xxxxx?yyyyy
where the x's are regular letter chars, and the y's numbers 0-9.
Apache is truncating the filename in the GET request at the "?" - as this is traditionally used to delinate query params - and thus reporting the followying error
file xxxx not found.
How can I get Apache to not think the y's are query args, and are actually part of the static file name?
Thanks very much for help,
Don
If you have control of how the URLs are being output, you can escape the '?' chars, This would be %3F instead of the '?'. The URL would therefore be
http://example.com/abcdef%3f99999