I've got a really, really bad feeling about this...
Bob S
> On Jun 23, 2017, at 10:56 , Dan Friedman via use-livecode
> wrote:
>
> I second this motion! PLEASE! We must have some way to work BEFORE the
> eternals are loaded. Furthermore, we should be able to define where the
> external
I second this motion! PLEASE! We must have some way to work BEFORE the
eternals are loaded. Furthermore, we should be able to define where the
externals will be saved and loaded. Requiring that externals must be in the
same directory as the exe is far to limiting!
New DataGrids and fancy
On 2017-06-21 22:47, J. Landman Gay via use-livecode wrote:
Could you expand on this a little bit? StandaloneSaving/Saved are only
sent during a build, so I'm not sure how I'd use those to intercept a
startup message.
Yes but they could be used at standalone building time (probably will
requir
> On Jun 21, 2017, at 11:31 AM, Mark Waddingham via use-livecode
> wrote:
>
> Since 8, standalones have loaded their externals on startup - so no script
> runs before the standalone expects them to be where they should. One way to
> resolve this is to send a message *before* the externals are
On 6/21/17 1:31 PM, Mark Waddingham via use-livecode wrote:
Since 8, standalones have loaded their externals on startup - so no
script runs before the standalone expects them to be where they should.
One way to resolve this is to send a message *before* the externals are
bound, allowing the 'sp
On 2017-06-21 19:42, Richard Gaskin via use-livecode wrote:
One of the things I liked about SuperCard was that Bill Appleton had
written his own resource fork into his data file format. This allowed
SC to store any number of data and even code (XCMDs and DFCNs) within
the data fork, without rely
Dan Friedman wrote:
> With LC 8.1 and later, we’re now using tsNet rather than libURL.
> That’s fine. However, a Windows standalone that uses tsNet cannot
> even launch unless tsNet.dll is in the same directory as the
> standalone.exe. This makes deploying a single file on Windows
> impossible.
On Mon, Jun 19, 2017 at 3:31 PM, Dan Friedman via use-livecode <
use-livecode@lists.runrev.com> wrote:
> Greetings…
>
> With LC 8.1 and later, we’re now using tsNet rather than libURL. That’s
> fine. However, a Windows standalone that uses tsNet cannot even launch
> unless tsNet.dll is in the sa
Greetings…
With LC 8.1 and later, we’re now using tsNet rather than libURL. That’s fine.
However, a Windows standalone that uses tsNet cannot even launch unless
tsNet.dll is in the same directory as the standalone.exe. This makes deploying
a single file on Windows impossible. Which means yo
Thanks Paul. That’s just what I’ve done in versions prior to LC 9. I can tell
you that it does work in LC 7 and 8. Not sure what the issue is with LC 9, but
maybe somone in the know from LiveCode will see this post and share the magic
formula!?!
-Dan
>>That look to me like it should work. H
Hi Dan,
That look to me like it should work. Here is my code below which does
work. That said, it works under 6.7.x and earlier. I have not tested my
code under LC7+. In my case I have only 1 external but I want to load
the correct one for OSX or Window.
The whole "put (there is a folder tExtFile
Matthias,
Thank you, but I would like to use the new tsNet. Just want to deploy a single
file. Can’t believe there isn’t a way to do that!?!
-Dan
> there is a way to use the old libURL instead of the new tsNet external…
___
use-livecode mailing li
Paul,
Thank you for the advice. But, either it didn’t work, or I’m doing it wrong.
Here’s what I did:
on startUp
new inv stack "myExternals"
set the mainStack of stack "myExternals" to "myGreatApp"
set the externals of stack "myExternals" to pExternals
-- pExternals is a list of all the dll’s
Hi Dan,
there is a way to use the old libURL instead of the new tsNet external. If that
is sufficient for you then you just have to unload the tsNet library before
building the standalone.
To do this just execute this from within the message box:
dispatch "revUnloadLibrary" to stack “tsNetLib
On 4/4/2017 3:57 PM, Dan Friedman via use-livecode wrote:
> Anyone have any insight?
Externals (.dll files that an a LC external) can be added to a created
substack on startup by setting the externals of that new sustack to the
approriate names and paths and then the substack started as a Library
Ok, when we last left our hero…. I was able to save all the dlls and whatnot
into custom properties and save them at app launch (exact same structure as
when LC made them). The problem is, the EXE doesn’t recognize that the dlls
are in place. How do you tell the exe that they are there and to
Dan Friedman wrote:
> Also, what’s with this ginormous DLL “libcef.dll”? It’s 47.5MB.
> Anyone know what that’s related to?
It's the CEF browser engine used by the browser widget.
--
Richard Gaskin
Fourth World Systems
Software Design and Development for the Desktop, Mobile, and the Web
___
Thank you everyone for your suggestions. I’ve been doing it that way for years
(save the dll’s as needed at runtime). The problem is that it seems that an
EXE made from LC 9.0 won’t even launch if you include any items related to the
internet (Broswer, Internet, SSL, etc) unless the tsNet.dll
Can an empty file placeholder be created within preOpenStack, then extract
the real DLL when it is really needed?
On Apr 3, 2017 6:34 PM, "Dan Friedman via use-livecode" <
use-livecode@lists.runrev.com> wrote:
> So, I deliver a single file for my LC standalones on Windows. Any
> required DLLs or
Dan Friedman wrote:
> So, I deliver a single file for my LC standalones on Windows. Any
> required DLLs or other needed files are downloaded at runtime and put
> in place on launch. However, in LC 9.0.0 it seems there is a dll,
> “tsNet.dll” that must be in place to even launch! UG!! Is there
So, I deliver a single file for my LC standalones on Windows. Any required
DLLs or other needed files are downloaded at runtime and put in place on
launch. However, in LC 9.0.0 it seems there is a dll, “tsNet.dll” that must be
in place to even launch! UG!! Is there a way to deploy a Windows
21 matches
Mail list logo