- Mark as New
- Follow
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report
We are running LC ES2 so, according to About page in admin console we have
| ADOBE® LIVECYCLE® Process Management ES2 | 9.0.0.0 | SP2 |
Does this patch for 8.2.1.3 still apllies?
Is there a patch for ES2? It's obviously not fixed...
Anyway, I resolved my immediate problem by changing workspace source.
After some javascript debugging i was very suprised to find out that
my string url parameter from call:
__flash__toXML(createResourceContainer("workspacehr","Resource_B048A5A0-2157-D64F-1E49-74F49BD4CAE0","http://myserver:8080/workspace-server/
documents/247043599265782593-60/C:\LCGDS\docm1294225602154\uj7g56xyyow23629a1t8rdy03000tnjo","application/pdf"));
inside actual js function createResourceContainer becomes:
Backslashes were simply removed!!
After I figured out that
__flash__toXML(createResourceContainer(...
is actualy generated by:
ExternalInterface.call("createResourceContainer",
I just changed Workspace source file: ResourceContainer.as and in function createResourceContainer instead of:
ExternalInterface.call("createResourceContainer", Application(Application.application).parameters.swfId, containerId, url, contentType);
ExternalInterface.call("createResourceContainer", Application(Application.application).parameters.swfId, containerId, url.replace(/\\/g, ""), contentType);
effectively removing backslashes before they could reach javascript and cause problems with IE.
It still baffles me:
- how were these backslashes removed during js function call? when? why?
- how come that LC manages to sort out paths like: C:LCGDSdocm1294225602154uj7g56xyyow23629a1t8rdy03000tnjo
- why in the world LC server has to send itself its local temp file path via client in the first place
Views
Replies
Total Likes