Issues with minor variations to include_once() / require_once() paths

Hi there,

EXEOutput sounds like it could be a fantastic tool, but I am currently falling at the first hurdle!

I’m having an issue with the include_once() function not working as expected.

• In one file, I include_once() a path built using dirname(__FILE__).
• In another file, I include_once() a path built using a custom function that works differently.

Using print() statement I can see that there are minor variants in the string generated, but that they refer to the same file:

• D:\My Documents\exe_output_test\Data\libraries/ErrorHandler/ErrorConstants.php
• D:\My Documents\exe_output_test\Data\libraries\ErrorHandler/ErrorConstants.php

As you can see, the only difference is that in one path a forward-slash is used instead of a back-slash. This works fine in normal PHP which correctly recognises that this is the same file, but inside EXEOutput, these are treated as different and the file is loaded twice. This obviously breaks the application.

I should imagine there are other paths which PHP handles properly but which EXEOutput doesn’t, e.g.

• \My Documents\exe_output_test\Data\libraries\ErrorHandler/ErrorConstants.php
• D:\My Documents\exe_output_test\Data\..\Data\libraries\ErrorHandler/ErrorConstants.php
• .\libraries\ErrorHandler/ErrorConstants.php
• etc.

Is this a known issue? Is there a workaround? Is there a fix planned?

– HappyDog

This is a new issue, we’ll look into this.

That’s great.

Do you have any idea what sort of time-line we’re talking about for a fix?

We’ll try to fix this issue in ExeOutput 2.0, it’s a matter of weeks now.

Fantastic!

Very much looking forward to it.

– HappyDog

Any news on v2.0? It’s been somewhat more than a matter of weeks, by now!

Do you have an ETA?

Cheers,

– HappyDog

At the end of October / beginning of November, we’ll post a preview with Chromium engine only for registered users. It’s the engine that was completely rewritten to handle CEF v3. If things work fine, we’ll see whether we add Trident too or strip it to keep focused on Chromium improvements.

This doesn’t sound good for me and surely a lot of other users…

Sure Chrome is a good engine, but what about us who’ve been coding complex apps for Trident and patiently waiting for the V2 update? - does this mean you seriously might drop Trident from V2 altogether and not provide the promised fixes and updates for a Trident version?

Don’t worry, we don’t intend to drop Trident from V2. We’ll first release a preview for Chromium, but the final V2 will include Trident too. In future releases, we’ll watch what users need. If there is still a demand for Trident, we’ll keep it, especially since Microsoft now continues to improve HTML5 support.

Excellent, thanks for the reply, that puts my mind at rest! For me personally, it’s the support for IE7 Compatibility mode that’s important - just hoping Microsoft keep that mode available in future versions of trident too else it would mean some quite drastic changes to the entire interface of my app!

They already tried to remove compatibility modes from Internet Explorer once, but they changed their mind.

Yeah, I did hear about that. just gonna have to keep my fingers crossed… Although I’m sure there must be a hack to enable the use of an old custom mshtml if needed - at least I hope so - I’ve seen it done before - so must be a possibility?