I've posted the Documentation Editor code to GitHub. I'll try to add some
screen shots eventually.
https://github.com/bwmilby/DocEditorPlus
https://github.com/bwmilby/DocEditorPlus/raw/master/DocEditorPlus.livecode
Script index:
https://github.com/bwmilby/DocEditorPlus/blob/master/DocEditorPlus.
Graham Samuel wrote:
> It’s OK, I think, to provide more facilities for the ‘big picture’
> professionals, such as making it easier to use version control and
> to work in teams, and to have an ever-expanding set of functions
> and even platforms; but it’s not OK if this is at the expense of
> th
David Bovill wrote:
> My guess on this is that it is a basic field issue.
Easily testable:
1. Make a field
2. Type in it
3. Open the Script Editor
4. Type in it
If you see a significant difference, we'll know it lies in the SE
scripts and not the engine.
> One of the most frequent crashes
David Bovill wrote:
> Richard - thanks for the tip regarding using the template field - I
> was wondering if that would work on the server (see my latest post)
Oh yes. You made that requirement clear.
You can read and write to LC object properties in a faceless
command-line environment like C
has this been resolved?
when you moved the global declaration to the top it worked?
I keep an eye on reports like this because they are the most
worrisome kinds of things.
But I always trust that the programmer will find the error in their ways.
On Mon, Jan 21, 2019 at 5:44 PM J. Landman Gay
Your just about there. Look at "the result" from the executeShellCommand. That
where more detailed error info will be.
Just put a "Put the result" after the executeShellCommand
Ralph DiMola
IT Director
Evergreen Information Services
rdim...@evergreeninfo.net
-Original Message-
From: use
Seems like I didn't look hard enough - I found it in
revsavesasandroidstandalone.livecodescript in the revSaveAsMobileStandaloneMain
command script. The relevant bit is...
executeShellCommand pathToJavaC(), "-target 1.5 -source 1.5 -Xlint:none -d",
tClassesBuildFolder, "-cp", tClassPath, tClas
David:
> I'm working on a solution for this
> collaborative with the minimal possible barrier to entry
> integrated into developer workflow - that means the script editor
> personal project wiki's for the software a developer is working
> on directly from the script editor
> Thoughts? Feedba
Thanks Ralph - so, I enabled the Livecode UI stacks in the pref window and then
used the find window to search for the error string (or part of it at least)
but no results were returned. I also had a poke/search around in a couple of
rev stacks with Android in their names but I was none the wise
I've seen similar messages when building for mobile. I enable the IDE stacks in
prefs then search for the error string and look at the result of the previous
operation. Usually the reason for the fail is apparent. Not pretty but fast.
(one of the advantages of having the IDE written in LCS)
Ral
I’m having a problem building/testing an Android app on one of my two
development laptops (Macbook Air, LC 9.0.2, OSX Yosemite) – it comes up with
the following error message...
Unable to build app for testing: could not compile service support class.
It seems to work fine on another laptop wit
On iOS you can clear the notification badge number using
iPhoneSetNotificationBadgeValue (by setting it to zero), but how do you achieve
the same thing on Android?
Terry...
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this u
Bob ...while I tested the previous solution ...I have not yet gone through
the implementation of it for real but I think I will do what you
suggest. It makes sense ...it should work as long as no handlers are
running on the main stack, I can replace its script. Thanks.
On Tue, Jan 22, 20
Thanks Brian - if you have the tie to dig out that stack it would be great.
I have come across the handlers / libs a few times - but as its not
documented it takes a while to track down :)
It would be great to figure out how to get proper flow back to the main
project - so any thoughts on that wou
no it should'nt you're right Jacque
only i forced myself months ago to put globals at the top and this stack
script was already older and i had putted locals at the top, so i
misplaced and overlooked 1 global
this was my fault, a global after some locals:
local tThis, tThat, tAnother, tAgain
You do not need to make the splash stack the mainstack. Just include the actual
mainstack in the Stack Files of the splash screen stack, and when have code in
the splash screen stack that opens the main stack. Then you can still keep your
stack/substack structure of your project.
Bob S
> On
prothero--- via use-livecode wrote
> ...
> I’d love to get some feedback on one of my fixes. I’m not seeing any
> issues but I need to get feedback across a few machines (Windows/Linux) to
> confirm my changes before creating a pull request. If you are an advanced
> user and are willing to hack up
GFM syntax is used, but it does go through additional processing before being
turned into what we see in the IDE. All of that code resides in the IDE so it
can be leveraged to process the updates. I actually modified a stack that can
allow the editing of a doc and then preview it in a browser.
On Tue, 22 Jan 2019 at 14:40, Brian Milby via use-livecode <
use-livecode@lists.runrev.com> wrote:
>
> That license will not allow inclusion into the LiceCode dictionary as it
> requires any derivative works to carry the same license. For integration
> into the LiveCode project a CLA will need to
It sounds very ambitious. My main suggestion was for a shareable user additions
part of the dictionary that could be incorporated into the main dictionary at
some later date, if useful. It is so common to see user comments on web
content, that I don’t see how there could be a problem with licens
Just to clarify, I didn’t really mean to suggest that there was a plan - it’s
just that a lot of the creative energy around LC and its development seems to
be going away from this as if it were bad, basically because it’s hard to do
version control on binary stacks, as far as I can see. I do und
Bob,
You could just create the branch on your fork of the engine/IDE and post that.
I’ve not been doing as much over the past few weeks but would be game to make a
change and test (even build a version with it). I will say that I have not
noticed that much of an issue but my code projects are
Two comments initially:
That license will not allow inclusion into the LiceCode dictionary as it
requires any derivative works to carry the same license. For integration into
the LiveCode project a CLA will need to be signed by each author and their
contributions also submitted with copyright
Hi.
Something you must consider.
On the forum "Jerky Script Editor Scrolling".
Some fonts scroll far smoother than others.
Craig Newman
--
Sent from:
http://runtime-revolution.278305.n4.nabble.com/Revolution-User-f278306.html
___
use-livecode m
Yes - sorry about that - copy and paste from Script Editor to Chrome now
seems to bring across all the formatting - I'll get rid of it next time.
Richard - thanks for the tip regarding using the template field - I was
wondering if that would work on the server (see my latest post) - I think
it's a
>
> I’d love to get some feedback on one of my fixes. I’m not seeing any issues
> but I need to get feedback across a few machines (Windows/Linux) to confirm
> my changes before creating a pull request. If you are an advanced user and
> are willing to hack up a file within the Application bund
The change I made is in the Script Editor which is not related to the message
box. It’s a UX/performance issue that I’ve fixed. Nothing related to crashing
at all. More of a difference in opinion I guess. My way is much better — for me
anyways :-) I’m betting others will agree though.
I’ve not
My guess on this is that it is a basic field issue. One of the most
frequent crashes I get is if in testing I put some data in the msg box. If
the data is unusually large, everything jams. Only a force-quit gets you
out of that.
I wonder if when we have native field objects - that this might be th
The script editor in Livecode is absolutely horrid performance wise. There
plenty of issues but the scrolling performance bothers me to no end — AGAIN!
I develop on a 3 year old iMac 27” with 24G of ram. The Livecode IDE is by far
the worst IDE/Script Editor that I use (sorry to say). I’m findin
I'm working on a solution for this - it's kind of ambitious and won't be
ready to share publicly for about 3 months at a guess - but I'm happy to
share it with anyone who want to use GitHub and get deep into the issue.
*Quick outline of dictionary strategy*
1. It should be collaborative with
Does anyone have any thoughts on where Livecode server should go / is going?
I thought I'd throw out a few things that have been on my mind to see what
other people are thinking and where the actual underlying technology is
heading. Context - I use Livecode server and Revigniter - but not to the
f
31 matches
Mail list logo
