Passing UNC path as parameter in URL

Question

Hello All,
I used the application creation wizard (APEX 3.1) to create an application (report + form) based on a table who's primary key is a UNC path to an image (\\servername\folder\image.tiff). The report page (page 1) has a link to the form where users can edit information for the record (page 2). Unfortunately, every time I click on a record's link, page 2 comes up with "No data found."
I know this has to do with the fact that the data I'm passing has backslashes ("\") and they're not being escaped properly. The branch properties show the target as "Page in this Application" where the UNC path is being passed to an item on page two that is hidden and protected.
I've tried a few different things to try and work around this problem:
1.) In my main query, selected another field based on the original UNC Path, but with the backslashes replaced with pipes ('|'). I then have a process on page 2 at the "on load" point before the fetch row that converts it back to backslashes. This works so far as pulling the correct record onto page two, but whenever I update anything the update statement is still looking for the UNC with pipes rather than the backslashes. I'm assuming because the item that I'm sending the value to is hidden and protected, that any HTML on that page won't be able to alter that value, so the pipes aren't being replaced with the backslashes.
2.) I also tried using a javascript:window.document.location.href... function and adding extra backslashes in the UNC path to escape the original ones, but this didn't work.
I was wondering if anyone had any other suggestions on how to pass this value without changing the item to unprotected.
Thank you,
Teddy

Answer 1

Teddy,
No bother at all. A long time ago, perhaps in version 1.6, we added the feature that allows "item values" containing commas to be passed in the "f?p" URL. As you know, the comma is the token that separates item values (if there is more than one). But it was becoming increasingly common for developers to need to allow that character as part of an item value. This was implemented such that if an item value starts and ends with a backslash then we would treat any comma between the two as part of the item value and not as a "separator" character.
When you tried to pass the UNC path as an item value, because this started with a backslash, the parser treated it as the beginning of a backslash-enclosed value. Failing to find a closing backslash, it yielded undesirable results and discarded the first backslash, and perhaps more.
In other words, it's a bug that what you tried did not work. But the solution is straightforward so I'm going to leave it at that, if you agree.
Scott