Pre-load RevBrowserCef to shorten launch time [Solved]

[Steve Collins]

Sorry, I didn't address the compression part. It's standard gz but to be sure it's compatible with LC, do the compression in LC too. Use LC's "compress" command. It's the same three lines I posted with only the one command changed.

Compress only works with single files. If you need externals or other supporting files you'll need to do each one separately. But I was suggesting you leave the videos on the flash drive and only copy the app itself.

Thanks, Jacque.

Since last night, I retraced my steps and went back to the sample unZip stack approach. Turns out this reported in the forum, and I thought happening to me when only 1 of many parts of the exe and External were showing up, has been fixed or was unique to the user (me included):

> Yes but you have to know that revZipEnumerateItems only works until LC 6.7.1

revZipEnumerateItems is working and so is my app now.

I just need to try that shell command to fix the Mac unix file getting tweaked to a text file with revUnzip. Tried all the above compression types and none prevent the tweak.

[Steve Collins]

Opening the MacOS folder in the Contents and replacing the "MyApplication" file fixes the bad app. Turns out it's supposed to be a Unix executable but when unzipped via LC it becomes a TextEdit Document, according to Get Info.

Not sure why the executable bit is carried over by other tools but not the Zip libs LC uses, but you can call chmod +x on the file using LC's shell function to turn it back into an executable file.

Beautiful! Works great.

Code: Select all

put "/Users/myusername/Library/Caches/TemporaryItems/AppFolder/MyApplication.app/Contents/MacOS/MyApplication" into tUnixFile
get shell("chmod +x" && QUOTE & tUnixFile & QUOTE)

Found 4 more Unix files in the CEF that needed to be fixed. Above approached worked great for them. CEF browser now working with app unzipped.

[Steve Collins]

Help! One last snag found.

CEF browser does not work when called with my standalone MyApplication (residing in the Temp folder with its Externals folder) on Windows when launched by another standalone LaunchApp (from flash drive or Desktop). But, when LaunchApp STACK (while running in LC) launches the same standalone MyApplication from a flash drive or standalone MyApplication is double clicked manually to launch it, CEF browser works fine. Non-CEF browser works fine on all occasions. For Mac, there are no problems with either CEF or non-CEF browsers using standalones made at the same time as Windows.

Fails at this line: put revBrowserOpenCef(tWindowId, tPath) into tBrowserId
No browser gets opened (which should open even if content is not at hand) and it never gets to the next script, which is just an answer script to see if it got that far. This error message is not activated because it never gets there:

Code: Select all

if tBrowserId is not an integer then
    answer "Error opening browser: " & tBrowserId
    exit altBrowserOn
 end if

Is there a special request needed in Windows for an app to launch another app so that it has access to its Externals folder.'

Update: Just tried launching with this shell command and same problem, launched standalone but no CEF will load when called:

Code: Select all

put "start" && quote&quote && quote& "C:/Users/Steve Collins/AppData/Local/Temp/EdelbrockWin/Windows/Edelbrock.exe" & quote into myStart
get shell(myStart)

Also noticed, when standalone MyApplication is launched directly or via stack launch script, in addition to CEF working, a debug document is created in the same directory as the standalone MyApplication and externals at launch before using CEF:

[0321/102620:WARNING:resource_bundle.cc(286)] locale_file_path.empty()
[0321/102620:ERROR:main_delegate.cc(550)] Could not load locale pak for en-US
[0321/102621:WARNING:resource_bundle.cc(286)] locale_file_path.empty()
[0321/102621:ERROR:main_delegate.cc(550)] Could not load locale pak for en-US
[0321/102621:WARNING:resource_bundle.cc(286)] locale_file_path.empty()
[0321/102621:ERROR:main_delegate.cc(550)] Could not load locale pak for en-US
[0321/102621:ERROR:renderer_main.cc(227)] Running without renderer sandbox
[0321/102621:ERROR:audio_low_latency_output_win.cc(169)] Bailing out due to non-perfect timing. Buffer size of 480 is not an even divisor of 1056
[0321/102906:WARNING:resource_bundle.cc(286)] locale_file_path.empty()
[0321/102906:ERROR:main_delegate.cc(550)] Could not load locale pak for en-US
[0321/102906:ERROR:renderer_main.cc(227)] Running without renderer sandbox

Could it be something is preventing the use of the standalone MyApplication's externals when there are errors and launched by remote app?

Update: No problems on Windows XP. Above is with Windows 10 on a new machine, no virus protection that I noticed, older model chip.

[jacque]

I know little about how Windows deals with this stuff, but my guess would be a restriction preventing one app from controlling another due to malware protections. Or maybe it's just a permissions issue.

Anyone know?

[Steve Collins]

I know little about how Windows deals with this stuff, but my guess would be a restriction preventing one app from controlling another due to malware protections. Or maybe it's just a permissions issue.

Anyone know?

I was just able to launch the app from Powershell in Windows 10, with CEF working, using this code:
start "C:/User/Steve Collins/ApplData/Local/Temp/FolderWithApplication/FolderInThatFolder/MyApplication.exe"

It produced a similar, but smaller, set of error details that occurred with successful launches of the app with a double click or stack launch, but noted them in the Powershell instead of a log file.

That script is pretty much what I used with LC shell script, which launched the app where CEF was not accessible by the app. Perhaps LC uses shell and Windows 10 uses both shell and Supershell (like it does with IE for LC resources and Edge for direct browsing).

I've read some references to PowerShell in this forum, but no actual working scripts to launch an app. Thinking a script to use the would fix this.

Update:

I think this invokes the Powershell service on Windows 10, but same problem. Loads app but not CEF.

set the shellCommand to PowerShell
put "start" && quote&quote && quote& "C:/Users/Steve Collins/AppData/Local/Temp/MyAppFolder/Windows/MyApplication.exe" & quote into myStart
get shell(myStart)

[Steve Collins]

Is there a way to force a standalone to launch it's externals, in this instance where they are not loaded or connected for loading at initial launch? Seems like it can't find them when launched by my standalone launch app. Specifically, the Standalone can't find the CEF software that resides in the Externals folder right beside the .exe, except when the standalone is double clicked or launched by a stack running in LC. Mac has no problem with this.

Drilling down to how Externals work, looks like the DLL file (which resides next to the externals in the Externals folder) is responsible for linking the external to the application. I'm getting the impression the standalone can't find or use the DLL file and I need to relink it. (DLL file must be fine, because works when standalone is double clicked.)

Update:

Read elsewhere about DLL files not working. Sometimes the path linking them to the app is wrong. When my Standalone is launched remotely from another app, the defaultFolder is set to the launching app's location. So "answer the defaultFolder" returns "E:/" in my openStack handler, which is wrong. The standalone is actually in the temporary folder. When double clicking the standalone in the Temporary folder, the initial defaultFolder is reported correctly as the temporary folder. Resetting the defaultFolder does not fix the CEF not working problem, though. I suspect that initial incorrect default folder is saved elsewhere in the standalone, and the defaultFolder is not used for finding the Externals. If this is the broken link, how do I reset that path so the standalone can find it's Externals folder.

Update:

Tried setting "set the externals of this stack to pathToExternals" no luck

[Steve Collins]

Solved! "Windows 10" use of standalone externals problem

When launching "Standalone 2" in an a folder (directory) using "Standalone 1" from a different folder, the defaulFolder setting for "Standalone 1" carries forward to "Standalone 2". So "Standalone 2" thinks it is in a different folder and can't find its Externals folder, because relative path is used to find them.

If you set the default folder in "Standalone 1" to the default folder where "Standalone 2" resides, "Standalone 2" sets its default folder to that made-up default folder. Keep in mind "Standalone 1" now has an incorrect default folder setting (no big deal if closing it or you can reset it after launch).

But! This does not work if you reset "Standalone 1" default folder before it is done unzipping and placing "Standalone 2" into its remote folder. Apparently, when "Standalone 1" has things to do, it resets its default folder to the correct folder, even if you just reset it to the made-up folder. So you have to place the defaultFolder reset after some certain tasks occur in a standalone being used to launch another. I placed mine toward the end of openStack but before a process that opens/writes/closes a text document in the same folder as where "Standalone 2" was just unZipped and placed.

This was not an issue with Windows XP. Above is needed for Windows 10 as of 3/23/16. I assume Windows 10 changed the way it handles default folders in this scenario.