Avatar

Level 2

We are running LC ES2 so, according to About page in admin console we have

ADOBE® LIVECYCLE® Process Management ES29.0.0.0SP2

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:

http://myserver:8080/workspace-server/documents/247043599265782593-70/C:LCGDSdocm1294225602154uj7g56...

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);

i wrote:

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