Tree View / Custom Properties PI

[Brian Milby via use-livecode]

Before going too far, I'd like to get some feedback on the best way to
address one of the issues that Curry brought up.

Currently, when in the Tree View widget (which is used in the Custom
Properties PI), if you click on the "+" icon to add a new array key, the
value in the existing key is lost if it is not already an array.  My
proposal here is to migrate the value to the new key (1).  If you clicked
the "+" again, then you would get the normal new key (2) with an empty
string as the value.

Line 1514 of the treeview.lcb file:
put **tElement** into tArray[1 formatted as string]

What is probably a bigger potential issue is if you set a value on a key
that is currently an array.  If that is done in the PI, then the sub-array
is lost and replaced with the value.  Still thinking on this piece (but the
change is going to be in the PI and not the Tree widget).  I'm thinking
that a confirmation dialog is appropriate here.

Here's a fix for (much of) the text selection issue:

Mac path:   LiveCode9.app/Contents/Tools/Toolset
/palettes/inspector/behaviors/revinspectoreditorbehavior.livecodescript

add the following handler:

after openField
   select the text of the target
end openField

That will auto-select text in the PI in many cases.  There is a need for
another statement in the custom properties behavior (here are lines 69-73
in the 9.0.1 source; 72 is the new line):
/palettes/inspector/editors/com.livecode.pi.customprops.behavior.livecodescript

  if the result is empty then
 put tKey into field "value" of me
 put item -1 of tPath into field "key" of me
 **select the text of field "key" of me**
  else

I have not looked into automatically selecting the newly created key, but
with the above 2 additions when you click on a line in the tree view widget
the key is selected with focus and ready for edit.  A tab will take you to
the value field with the text selected.

So, it looks like adding 4 lines of code to the IDE and changing 1 word in
the Tree View widget source can remove a few of the irritation points.
Before submitting anything, I do want to see if I can identify where to
address the resize issue mentioned above.

Thanks,
Brian
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Regaining IDE Efficiency: Property Inspector

[J. Landman Gay via use-livecode]

Me either. I tried to like them, and tested at least three, and even made 
my own. But in the long run it's all muscle memory for me. I need 
landmarks, and colors aren't enough.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On August 9, 2018 7:13:27 PM Mike Kerner via use-livecode 
 wrote:



I'm not a fan of sheets.  I find myself doing constant scrolling because
the property I'm looking for never seems to be on the screen, or if I'm
changing multiple properties and messing with settings to see what the
combination does, I'm constantly going up down up down, overshooting the
property, having to scroll-scroll-scroll to get to the right spot.  You
can't take advantage of the 2D space (think about the position tab in the
PI as the most obvious example) to organize related properties.  You also
can't use graphics or group boxes, shadows, colors, or backgrounds to make
it clearer how properties are associated with each other.

Shortcuts to switch tabs in the PI would make navigating better, IMHO.
Ctrl-right arrow or ctrl-left arrow, ctrl-1..n would make flipping between
pages faster, but the layout and the proximity of the tabs to the
properties now still makes navigating between multiple pages of properties
for an object and fiddling with them much faster than a sheet does.

On Thu, Aug 9, 2018 at 7:44 PM Mark Wieder via use-livecode <
use-livecode@lists.runrev.com> wrote:


On 08/09/2018 04:21 PM, Curry Kenworthy via use-livecode wrote:

> Hint: A property sheet doesn't necessarily need to look like one.

True, but it also shouldn't get in my way.
And you've done a great job in listing most of the annoyances of the PI.

--
  Mark Wieder
  ahsoftw...@gmail.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode




--
On the first day, God created the heavens and the Earth
On the second day, God created the oceans.
On the third day, God put the animals on hold for a few hours,
  and did a little diving.
And God said, "This is good."
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your 
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-livecode





___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Regaining IDE Efficiency: Property Inspector

[Brian Milby via use-livecode]

 I've briefly looked at a few issues and have some comments:

I should be able to put together something on the Custom Properties portion
of the PI.  I'm looking at the code and am not sure yet if the change needs
to be in the widget, the PI, or both.  I think that the widget should have
a warning before clobbering a value (just like it does before deleting).

I see why the tree is not shrinking, but am not sure how to fix it yet (the
height of "me" is not getting smaller).  It looks like the group grows but
does not shrink, so you get the behavior that we see.  If the group did
shrink, it would get positioned correctly.

For the PI, the raw keys are intercepted and scroll wheel is directed
toward scrolling the PI group.  So if you take the custom properties tab
and grow it and then shrink it then the scroll wheel should work as
expected to move the visible portion.

Control arrows could probably be implemented in that same section of code
if the community and corporate concurred.

Thanks,
Brian
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Regaining IDE Efficiency: Property Inspector

[Richard Gaskin via use-livecode]

Mike Kerner wrote:

> I'm not a fan of sheets.  I find myself doing constant scrolling

You're not using v9's PI? ;)


> because the property I'm looking for never seems to be on the screen,
> or if I'm changing multiple properties and messing with settings to
> see what the combination does, I'm constantly going up down up down,
> overshooting the property, having to scroll-scroll-scroll to get to
> the right spot.

True, prop sheets with views grouped by type and a Favorites view are best.


> You can't take advantage of the 2D space (think about the position tab
> in the PI as the most obvious example) to organize related properties.

That's one.

> You also can't use graphics or group boxes, shadows, colors, or
> backgrounds to make it clearer how properties are associated with each
> other.

Why not?  Most sheets I've seen use the color/pat as the background for 
the value, pretty much as we see them in LC's PI.



> Shortcuts to switch tabs in the PI would make navigating better, IMHO.
> Ctrl-right arrow or ctrl-left arrow, ctrl-1..n would make flipping
> between pages faster, but the layout and the proximity of the tabs to
> the properties now still makes navigating between multiple pages of
> properties for an object and fiddling with them much faster than a
> sheet does.

Do we even have a keyboard shortcut to move focus to the Inspector?

Back when I used to use Adobe products they used Cmd-, to shift focus to 
their inspector.


Even if we do, though, since any palette has a global-ish scope how 
would the developer using it know when a shortcut is handled by the 
Inspector and when it's handled by their own app's menubars or other 
shortcut-driven features?


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Regaining IDE Efficiency: Property Inspector

[Mike Kerner via use-livecode]

I'm not a fan of sheets.  I find myself doing constant scrolling because
the property I'm looking for never seems to be on the screen, or if I'm
changing multiple properties and messing with settings to see what the
combination does, I'm constantly going up down up down, overshooting the
property, having to scroll-scroll-scroll to get to the right spot.  You
can't take advantage of the 2D space (think about the position tab in the
PI as the most obvious example) to organize related properties.  You also
can't use graphics or group boxes, shadows, colors, or backgrounds to make
it clearer how properties are associated with each other.

Shortcuts to switch tabs in the PI would make navigating better, IMHO.
Ctrl-right arrow or ctrl-left arrow, ctrl-1..n would make flipping between
pages faster, but the layout and the proximity of the tabs to the
properties now still makes navigating between multiple pages of properties
for an object and fiddling with them much faster than a sheet does.

On Thu, Aug 9, 2018 at 7:44 PM Mark Wieder via use-livecode <
use-livecode@lists.runrev.com> wrote:

> On 08/09/2018 04:21 PM, Curry Kenworthy via use-livecode wrote:
>
> > Hint: A property sheet doesn't necessarily need to look like one.
>
> True, but it also shouldn't get in my way.
> And you've done a great job in listing most of the annoyances of the PI.
>
> --
>   Mark Wieder
>   ahsoftw...@gmail.com
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>


-- 
On the first day, God created the heavens and the Earth
On the second day, God created the oceans.
On the third day, God put the animals on hold for a few hours,
   and did a little diving.
And God said, "This is good."
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Regaining IDE Efficiency: Property Inspector

[Mark Wieder via use-livecode]

On 08/09/2018 04:21 PM, Curry Kenworthy via use-livecode wrote:


Hint: A property sheet doesn't necessarily need to look like one.


True, but it also shouldn't get in my way.
And you've done a great job in listing most of the annoyances of the PI.

--
 Mark Wieder
 ahsoftw...@gmail.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Regaining IDE Efficiency: Property Inspector

[Monte Goulding via use-livecode]

> On 10 Aug 2018, at 9:07 am, Curry Kenworthy via use-livecode 
>  wrote:
> 
> Whatever you need is absolutely fine with me, feel free to parse and 
> slice/dice this into any number of pieces with my blessing.

OK for anyone else following along the best way to discuss issues with us is to 
follow the bug reporting guidelines. Here they are FYI 
https://quality.livecode.com/page.cgi?id=bug-writing.html 


Cheers

Monte
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: stackfiles

[Richard Gaskin via use-livecode]

Bob Sneidar wrote:

> On Aug 9, 2018, at 11:45 , Richard Gaskin wrote:
> Yes, the stackFiles property is every bit as global as any other use
> of stack names.
>
> Not to belabor the point, but the stackfiles is a property of a STACK,
> not a global system property.

A stack's name is also a property of a stack, but anything involving 
stack names has global effects.


The stackFiles property allows us to use the short name of a stack file 
to easily access that stack.


Once the stack with the stackFiles list is loaded, all those references 
are loaded with it.  The same mechanism that allows scripts in that 
stack to call other stacks by short name allow any other scripts 
anywhere else to use that same name, because stack names have global 
effects.


Besides, even if you had two stacks whose stackFiles had the same stack 
short name assigned to different stackFiles, one of them wouldn't work 
anyway because as soon as it tried you'd get a stack name conflict warning.


Simpler to just remember that stack names have global scope, then you 
can plan accordingly with consistent simplicity.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Regaining IDE Efficiency: Property Inspector

[Curry Kenworthy via use-livecode]

Richard:

> Many (most?) development environments use a property sheet

Wieder:

> I'm a big fan of property sheets.

Hint: A property sheet doesn't necessarily need to look like one.

It could be useful to consider the value that the past and current PI 
appearance has for users. The effect it has. It's a very user-friendly 
look, isn't it? So easy to locate things visually too.


We could ask ourselves if that factors into any buying decisions. It 
probably did for me. At the time I wasn't really looking for just "yet 
another dev tool." There were plenty of those but I didn't go that route.


But behind the scenes ... much can happen. And probably should happen. 
Without necessarily changing the look that people know and love. :)


I'm capable of doing that, and others are too. Good food for thought. 
Back to work


Best wishes,

Curry Kenworthy

Custom Software Development
LiveCode Training and Consulting
http://livecodeconsulting.com/

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Regaining IDE Efficiency: Property Inspector

[Curry Kenworthy via use-livecode]

Monte:

> We really need a single report per issue.

Howdy Monte! Whatever you need is absolutely fine with me, feel free to 
parse and slice/dice this into any number of pieces with my blessing.


However I myself will NOT be filing dozens or hundreds of report; 
impossible. I wasn't kidding or exaggerating the slightest bit about not 
having time for that; wish I did, but think of it ... I've been waiting 
for a whole YEAR just for the chance to get this first list done, and 
now it's done! Mark wanted some specifics and here they are.


Also this is very much a gift to LiveCode, perhaps far more to your own 
benefit, not just a selfish request of my own.


> with recipe on how to reproduce

Each is described clearly, with all the info actually needed.

> it would be great if we had more Brian Milbys ...
> around that like to jump in and get involved.

Yes it would! I heartily agree with you, amazing and greatly appreciated 
when people contribute, and I wish it were possible for me to donate 
more time to LC. (Beyond the 10 hours this list has taken to test and 
compile, and many dozens devoted to producing reports on LC 7 issues 
during that transition.)


But right now it's just not physically (or temporally) possible for me. 
I have less free time and a bigger todo list than it might be possible 
for you to imagine. I'm sorry about that.


But perhaps that would make more sense if I pointed out that YOU also 
are not donating time working on MY code either! :) However, if you're 
short of people, I certainly would be available for some part-time paid 
work on the IDE, and highly likely to improve on some of what you have 
there. I know my stuff.


> IDE usability niggles

Ha! I think the visible face of LiveCode that every user sees, along 
with the level of efficiency provided for doing useful tasks with it, 
might just rise to a slightly different phrase than "niggles." That got 
a real-life audible chuckle out of me just now! Wow. Still chuckling. 
That'll keep me smiling for a bit.


Anyway, thank you sincerely for your comments and attention. I would 
love to see these issues improved, and there's no possible doubt that 
fixing the IDE would certainly be at the very minimum 100% as much to 
your benefit (and likely far, far more to yours) as it would be to my 
own. Not to mention all the others here. LC is a very special product, 
and we have a very special love for it. What a difference it makes in 
our lives! There's nothing that comes anywhere close to it. So I'd love 
to see the UI 100% back on its feet again. The love is real. I have to 
wrap up this reporting now and get back to my normal tasks which are 
piling up as we speak. Keep up the great work!!


Best wishes,

Curry Kenworthy

Custom Software Development
LiveCode Training and Consulting
http://livecodeconsulting.com/

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Regaining IDE Efficiency: Property Inspector

[Mark Wieder via use-livecode]

On 08/09/2018 08:14 AM, Richard Gaskin via use-livecode wrote:

Many (most?) development environments use a property sheet* instead, to 
handle the deep, rich variety of detailed properties developers need to 
control.


Much like revNavigator, no? 
I'm a big fan of property sheets.

--
 Mark Wieder
 ahsoftw...@gmail.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: stackfiles

[Bob Sneidar via use-livecode]

Not to belabor the point, but the stackfiles is a property of a STACK, not a 
global system property. It would be like setting the foo of stack "test1" to 
the filename of stack "splash", quitting LC, relaunching LC, opening stack 
"test1", then expecting to be able to open stack "splash" using it's short 
name. It's obvious that won't work, so you wouldn't expect the filenames 
property to make "splash" accessible simply by opening "test1". 

But knowledge is power, and as long as we are all aware, it doesn't matter that 
much to me. 

Bob S


> On Aug 9, 2018, at 11:45 , Richard Gaskin via use-livecode 
>  wrote:
> 
> Bob Sneidar wrote:
> 
> > How odd though. The stackfiles is acting like a global property.
> > Imagine I have 2 projects open, each referencing 2 different versions
> > of the same stack in different locations on the disk. Any attempt to
> > open that stack using it's short name might yield the wrong stack.
> 
> Yes, the stackFiles property is every bit as global as any other use of stack 
> names.


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Regaining IDE Efficiency: Property Inspector

[Monte Goulding via use-livecode]

> On 10 Aug 2018, at 1:53 am, Curry Kenworthy via use-livecode 
>  wrote:
> 
> Here's the QA enhancement request for Property Inspector defects:
> 
> https://quality.livecode.com/show_bug.cgi?id=21479 
> 

Hi Curry

We really need a single report per issue. After all you wouldn’t like to see a 
release note for bug 21479 being “Fixes various property inspector issues Curry 
noticed”. One report per issue, with recipe on how to reproduce means we can 
focus on implementing the actual fixes rather than having to task someone with 
creating reproducible recipes and individual reports.

As Richard mentioned it would be great if we had more Brian Milbys (or is that 
Milbies ;-) around that like to jump in and get involved. The reality is with 
limited resources the team ends up having to prioritise engine issues over IDE 
usability niggles so the help is appreciated.

Cheers

Monte
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Intersect outputs different result in desktop and LC server

[Alex Tweedly via use-livecode]

I think LC9 is faster, but I've never tested, so that's purely "anecdotal".

Yes, I believe it does mean that a new stable release will replace the 
older one; I've quoted Robin's mail from my support ticket conversation 
below ...


This might be worth a discussion with on-rev support, to see whether 
there might be a way they could make available newer version, but allow 
guaranteed access to the "older" version for some time after the new one 
becomes available so we can all test against it.


I'm sure that if you had to revert (or remain) on an older version, they 
would be helpful in supplying a way to do that specific to your account 
- but maybe there would be a general way to do it that would make the 
option available to all users.


I don't know if anyone on the on-rev team follows his list. Anyone there ?

-- Alex.


Dear Alex,

Yes, that is the plan: when 9.0.1 goes to stable I will update the server so
that .lc9 serves 9.0.1 and 9.0.0 becomes unavailable. I think that's the best
way of managing it.

Regards,

Robin



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Intersect outputs different result in desktop and LC server

[jbv via use-livecode]

Hi Alex,
Thanks for the tip. I'm on sage too.
Is it me or is LC9 server much faster than previous versions ?

One more thing : you wrote :
"any file with extension .lc9 will use the latest stable release of LC9"
Does that mean that LC server will be updated every time a new stable
version is released ? And if yes, is it safe to fo into production with
.lc9 scripts ?

Best,

On Thu, August 9, 2018 1:02 pm, Alex Tweedly via use-livecode wrote:
> I sent a support request asking for it :-)
>
>
> AFAIK, at least on sage, it is installed systemwide - so any file with
> extension .lc9 will use the latest stable release of LC9 (this is a similar
> scheme to what HostM use).
>
> I suspect you can use .htaccess to ensure it is used for all .lc files,
> but I didn't do that; I kept all the old stuff unchanged, and use the .lc9
> extension in the two files I need it (they then load other .livecodescript
> libraries, and some other .lc files, so I got all my old functionality by
> renaming these two files, and redirecting a couple of URLs).
>
>
> -- Alex.
>
>
>
> On 09/08/2018 06:52, jbv via use-livecode wrote:
>
>> How do you run LC9 server on on-rev ?
>> Thanks.
>>
>>
>>
>> On Thu, August 9, 2018 1:40 am, Alex Tweedly via use-livecode wrote:
>>
>>> Oops - sent before I meant to ...
>>>
>>>
>>>
>>> With LC7 server on on-rev, I get
>>>
>>>
>>>
>>> 4141 5378 18699 28365 41200 50230 58901 62983 63416 65984 71574 73426
>>>  74288 112360 115826 121386 126039 141224
>>>
>>>
>>>
>>> while with LC9 server on on-rev I get
>>>
>>> 4141
>>>
>>>
>>>
>>> -- Alex.
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>> ___
>> use-livecode mailing list use-livecode@lists.runrev.com Please visit this
>> url to subscribe, unsubscribe and manage your subscription preferences:
>>  http://lists.runrev.com/mailman/listinfo/use-livecode
>>
>
>
> ___
> use-livecode mailing list use-livecode@lists.runrev.com Please visit this
> url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
>



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Regaining IDE Efficiency: Property Inspector

[Richard Gaskin via use-livecode]

Curry Kenworthy wrote:

> Here's the QA enhancement request for Property Inspector defects:
>
> https://quality.livecode.com/show_bug.cgi?id=21479

Thanks for submitting that, Curry.

I have a dream in which an increasing amount of IDE stuff gets done by 
the community, leaving more C++ programmers available for the stuff that 
needs C++ programmers.


That said, I have to admit I'm pressed for time this month myself, so 
I'm a poor example.


But since this is all scripting work, is there anyone with the 
intersection of time, skills, and interest available to take some of 
this on?


Obviously the team will get to it soon, but the more we work on IDE 
stuff the faster both that and engine work gets done. Mo' better LiveCode!


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: stackfiles

[Richard Gaskin via use-livecode]

Bob Sneidar wrote:

> How odd though. The stackfiles is acting like a global property.
> Imagine I have 2 projects open, each referencing 2 different versions
> of the same stack in different locations on the disk. Any attempt to
> open that stack using it's short name might yield the wrong stack.

Yes, the stackFiles property is every bit as global as any other use of 
stack names.


To handle different versions of a stack, I use different LC instances.

FWIW ever since v5 (maybe earlier?) LC's clipboard preserves objects 
with complete fidelity even when pasting between instances, making the 
task of working on both a breeze.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Tutorial for MAP widget

[Andrew Bell via use-livecode]

Klaus-

After further inspection I agree with you that this widget needs a  
proper tutorial. I was looking at the module itself trying to find  
some undocumented features (like a polygon or circle overlay instead  
of just a polyline) and came up empty handed.


After looking at the W3Schools tutorial @  
https://www.w3schools.com/graphics/google_maps_overlays.asp I noticed  
that you could create multiple polyline segments using the native  
Google Maps API. The demo code in the LC 9.0.0 docs (not the  
dictionary, but the doc referenced in my previous post) uses the  
following example:


   put "55,-3,55,-5" into tPolylines["line"]["coordinates"]

It isn't documented, but this is a comma delimited list of lat/long  
value pairs (also separated by a comma) to be used as points for  
connecting line segments. So in the provided example a line segment is  
drawn from "55,-3" to "55,-5" on the map. But you can draw a triangle  
between Edinburgh (55,-3), New York (40,-74), and Cairo (30,31) then  
back to Edinburgh with this:


   put "55,-3,40,-74,30,31,55,-3" into tPolylines["line"]["coordinates"]

The closed triangle needs 4 sets of coordinates, not just 3, so it can  
return to the "home" point. Still not quite the polygon overlay that  
the Google Maps API provides, but a neat option that wasn't evident by  
reading the current documentation.


It's also not explicitly documented that the "color" property will  
accept a RGBA value so the following example provides an orange-ish  
overlay with a ~39% opacity (100 / 255):


   put "228,128,0,100" into tPolylines["line"]["color"]

In fact, the dictionary reference for polylines only shows RGB as an  
example. This is an extremely powerful widget... if you know what it  
is actually doing.


--Andrew Bell



From: Klaus major-k 
To: How to use LiveCode 
Subject: Tutorial for MAP widget
Message-ID: 
Content-Type: text/plain;   charset=us-ascii

Hi all,

could someone (the mothership?) please create a little tuorial
for the new MAP widget? This is really not self-explaining.
How to let the user create a new marker etc...

Thanks a lot!


Best

Klaus
--
Klaus Major
http://www.major-k.de
kl...@major-k.de





___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: HTML to text in field

[Richmond Mathewson via use-livecode]

Hmm . . .

On 9/8/2018 4:21 pm, David V Glasgow via use-livecode wrote:

Thanks Richmond, I will mess about with your suggestions.  It's always much 
appreciated when someone takes the time to suggest a complete handler.

But …. I want more!

*
**Just as long as I can call you Oliver Twist. :)*


  Can you see anything wrong with this?


replaceText (ttemp, "<*>", "|")

*
**Dunno, I have NEVER used replaceText.

One thing I do know is that the in-built Dictionary in LC 7.1.4 is much
more Richmond-friendly than that in the 8 and 9 series.

Might not be a bad idea to try double quotes round 'ttemp': yes, I know that
sounds bonkers, but . . .

Ah, wait a malformed moment . . . I think you have got 'that' all wrong 
insofar as I don't think
you can use a string-variable as the first term inside the brackets of a 
replaceText thingy (I use the term 'thingy' advisably as

I haven't a clue whether replaceText is a function or something else) . . .

Have a go with this ever so-slightly retro, mechanical thing:

put ttemp into fld "TTTEMP"
replaceText (fld "TTTEMP", "<*>", "|"

Well it is probably a better bet than a sharp stick in the eye!
*


or have a clue about the error message?

  “button "Import HTML": execution error at line 7 (Handler: can't find handler) near 
"replaceText", char 1”


*Read "my crap" above.

Gosh, this Belarussian Stout really makes me 'artistic'.

Richmond.
*


Cheers,

David G
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: HTML to text in field

[Richmond Mathewson via use-livecode]

Possibly as it was lifted verbatim from "elsewhere'. :/

Although it works the way it is in LC 8.1.10.

Richmond.

On 9/8/2018 4:31 pm, Richard Gaskin via use-livecode wrote:

Richmond Mathewson wrote:

>put (URL ("file:" & it),"UTF8") into CHEESE

Was uniDecode intended there?

--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.com http://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your 
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Regaining IDE Efficiency: Property Inspector

[Andrew Bell via use-livecode]

This one escaped me at first as well, but if you click on the sprocket  
widget in the upper-right of the PI you have the option for  
"Header/Footer Size" to grow and shrink the tabs. I'm not sure what  
"Footer" is referring to.


--Andrew Bell



PI window and tabs:

- The PI tabs (Basic, Contents, Custom...) are one thing that is almost
more efficient now than in 6. Good! But still needs improvement. I say
"almost" efficient because the little tab buttons are way too small -
about 11x10 px on my screen. That's takes more effort and concentration
to click, and these are your highest-traffic PI controls. Even 16x16
would be an improvement. Unless there's already a setting for this that
I missed.




___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Tutorial for MAP widget

[Andrew Bell via use-livecode]

Like this?
https://livecode.com/docs/9-0-0/components/map-widget/

I will be talking a little about my Map widget implementation during a  
LC Global talk next month.


--Andrew Bell


From: Klaus major-k 
To: How to use LiveCode 
Subject: Tutorial for MAP widget
Message-ID: 
Content-Type: text/plain;   charset=us-ascii

Hi all,

could someone (the mothership?) please create a little tuorial
for the new MAP widget? This is really not self-explaining.
How to let the user create a new marker etc...

Thanks a lot!


Best

Klaus
--
Klaus Major
http://www.major-k.de
kl...@major-k.de




___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: stackfiles

[Bob Sneidar via use-livecode]

Should be:
open stack tFullStackPath


> On Aug 9, 2018, at 09:23 , Bob Sneidar via use-livecode 
>  wrote:
> 
> open tFullStackPath


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: stackfiles

[Bob Sneidar via use-livecode]

The safe way then to do this would be:

put the stackfiles of stack "test1" into tStackFiles -- or whatever your stack 
is named
filter lines of tStackFiles with "splash*" -- or whatever your stack short name 
is
put item 2 of tStackFiles into tFullStackPath
open tFullStackPath

Bob S


> On Aug 9, 2018, at 09:17 , Bob Sneidar via use-livecode 
>  wrote:
> 
> How odd though. The stackfiles is acting like a global property. Imagine I 
> have 2 projects open, each referencing 2 different versions of the same stack 
> in different locations on the disk. Any attempt to open that stack using it's 
> short name might yield the wrong stack. 
> 
> I know you will say: "Well then, don't do that!" But lets say you have a 
> splash stack you use in multiple projects, or a custom dialog stack. You make 
> changes to one stack requiring an update to the other, but that would require 
> that you update ALL the stacks that use the other stack. Rather than do that 
> you might simply save a new version of the splash or dialog stack until you 
> can get around to updating and testing the others. 
> 
> Bob S


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: stackfiles

[Bob Sneidar via use-livecode]

How odd though. The stackfiles is acting like a global property. Imagine I have 
2 projects open, each referencing 2 different versions of the same stack in 
different locations on the disk. Any attempt to open that stack using it's 
short name might yield the wrong stack. 

I know you will say: "Well then, don't do that!" But lets say you have a splash 
stack you use in multiple projects, or a custom dialog stack. You make changes 
to one stack requiring an update to the other, but that would require that you 
update ALL the stacks that use the other stack. Rather than do that you might 
simply save a new version of the splash or dialog stack until you can get 
around to updating and testing the others. 

Bob S


> On Aug 9, 2018, at 09:06 , Bob Sneidar via use-livecode 
>  wrote:
> 
> Ah! I get it now. 
> 
> I tested this. 2 stacks, one with the stackfiles set to a third stack 
> somewhere on disk. Second one with a button that opens the stack listed in 
> the stackfiles of the first stack using it's short name. 
> 
> With both stacks open, Clicking the button opens the stack listed in the 
> stackfiles of the first stack. With only the second stack open, I get a 
> script error. 
> 
> So, yes!
> 
> Bob S


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: stackfiles

[Bob Sneidar via use-livecode]

Ah! I get it now. 

I tested this. 2 stacks, one with the stackfiles set to a third stack somewhere 
on disk. Second one with a button that opens the stack listed in the stackfiles 
of the first stack using it's short name. 

With both stacks open, Clicking the button opens the stack listed in the 
stackfiles of the first stack. With only the second stack open, I get a script 
error. 

So, yes!

Bob S


> On Aug 9, 2018, at 08:55 , Klaus major-k via use-livecode 
>  wrote:
> 
> Hi Richard,
> 
>> Am 09.08.2018 um 17:20 schrieb Richard Gaskin via use-livecode 
>> :
>> 
>> Klaus major-k wrote:
>> ...
>> When a stack file is included among the stackfiles property of an open 
>> stack, you should be able to address it by short name if you like.
> 
> thank you, that finally answers my question. 8-)
> 
>> -- 
>> Richard Gaskin
>> Fourth World Systems
>> Software Design and Development for the Desktop, Mobile, and the Web


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: stackfiles

[Klaus major-k via use-livecode]

Hi Richard,

> Am 09.08.2018 um 17:20 schrieb Richard Gaskin via use-livecode 
> :
> 
> Klaus major-k wrote:
> ...
> When a stack file is included among the stackfiles property of an open stack, 
> you should be able to address it by short name if you like.

thank you, that finally answers my question. 8-)

> -- 
> Richard Gaskin
> Fourth World Systems
> Software Design and Development for the Desktop, Mobile, and the Web
> 
> ambassa...@fourthworld.comhttp://www.FourthWorld.com

Best

Klaus

--
Klaus Major
http://www.major-k.de
kl...@major-k.de


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Regaining IDE Efficiency: Property Inspector

[Curry Kenworthy via use-livecode]

Here's the QA enhancement request for Property Inspector defects:

https://quality.livecode.com/show_bug.cgi?id=21479



Sorry I didn't see some of the replies here until already submitted, but 
feel free to add comments there, and sign on if you want this stuff done!


Paul/Bob: Yes, I tested all these with 901rc1.

Richard: You and I both love efficiency! I do think sheets are powerful. 
Then again LC already had a mostly very efficient IDE full of well-honed 
features in a well-designed format that were inexplicably lost when 
updating/porting/remaking. Efficiency already achieved and probably 
fairly easy to regain.


Brian: Ah, the gear can make the tab icons bigger! Thanks!!

BTW, at some point I'll do the same for other IDE areas and file 
separate Regain Lost Efficiency requests for those areas, but if anyone 
has spare time, feel free to beat me to it!


Best wishes,

Curry Kenworthy

Custom Software Development
LiveCode Training and Consulting
http://livecodeconsulting.com/


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: stackfiles

[Richard Gaskin via use-livecode]

Klaus major-k wrote:

> I mean if stack xyz has its stackfile property set, can other stack
> access this property just like the stack xyz scripts?

Every property of every object in every stack on your hard drive is 
available to every script.


An object does no need to be loaded into memory to be accessed.  If you 
query a property of an object in an unopened stack, the engine will 
faithfully read the stack and unpack it to return what you're requesting.


If the stack is already in memory, you can refer to it by short name.

  get the width of btn 1 of stack "MyStack"

In memory or not, you can refer to a stack by its filename:

  get the width of btn 1 of stack "/home/klaus/MyStack.livecode"

When a stack file is included among the stackfiles property of an open 
stack, you should be able to address it by short name if you like.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Regaining IDE Efficiency: Property Inspector

[Brian Milby via use-livecode]

- The PI tabs (Basic, Contents, Custom...) are one thing that is almost
more efficient now than in 6. Good! But still needs improvement. I say
"almost" efficient because the little tab buttons are way too small -
about 11x10 px on my screen. That's takes more effort and concentration
to click, and these are your highest-traffic PI controls. Even 16x16
would be an improvement. Unless there's already a setting for this that
I missed.

Yes... select the gear icon on the right. You can change the size and switch to 
text labels if you prefer.

Thanks,
Brian
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Regaining IDE Efficiency: Property Inspector

[Brian Milby via use-livecode]

I’ve done a bit of work in the tree widget, so I can take care of submitting a 
PR against a bug/enhancement request there.

Thanks,
Brian
On Aug 9, 2018, 9:56 AM -0500, Bob Sneidar via use-livecode 
, wrote:
> I'm using rc1, and the PI issues persist so far as I can see. As I mentioned, 
> the element portion of the PI is actually a tree widget, so some of the 
> issues are really with the tree widget, not the PI itself.
>
> Bob S
>
>
> > On Aug 9, 2018, at 06:23 , Paul Dupuis via use-livecode 
> >  wrote:
> >
> > My understanding from something I (think I) saw on this list was that
> > 9.0.1 is focused on IDE improvements. I have not yet downloaded 9.0.1rc
> > (my bad) but can any others who have downloaded comment if the IDE, and
> > PI in particular, is, in fact, improved? If so by how much (guestimate)?
>
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: stackfiles

[Klaus major-k via use-livecode]

Hi Bob,

> Am 09.08.2018 um 17:15 schrieb Bob Sneidar via use-livecode 
> :
> 
>> On Aug 9, 2018, at 08:07 , Klaus major-k via use-livecode 
>>  wrote:
>> 
>> I mean if stack xyz has its stackfile property set, can other stack access 
>> this property just like the stack xyz scripts?
> 
> If I understand you, then another stack can reference the stackfiles of xyz 
> by getting the stackfiles of stack xyz.

Ok, that my be one solution to my questions.

> But I cannot think that is what you meant. The stackfiles is a property of a 
> single stack, and not a global property. 

Well, so are the xternals and scripts of a stack, but other stack can use these 
if we "start using stack xyz".
And that fact led me to the conclusion that this may also apply to "the 
stackfiles" of stack xyz, which was my original question :-D
> 
> But I probably still do not understand. :-)
> 
> Bob S

Best

Klaus

--
Klaus Major
http://www.major-k.de
kl...@major-k.de


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Regaining IDE Efficiency: Property Inspector

[Richard Gaskin via use-livecode]

Inspectors are popular in drawing and layout programs, where object 
properties are relatively limited.


Many (most?) development environments use a property sheet* instead, to 
handle the deep, rich variety of detailed properties developers need to 
control.


Property sheets can help address everything in this list by:

- making better use of space, with more options visible at once

- being more complete, allowing all object properties to be available
  rather than just a selected subset

- providing more efficient navigation; accordion controls have a much
  larger target area than toolbar icons; good ones let you switch
  between grouped categories and one full list sorted by prop name.

- simplifying resizing so the entire resizing complexity goes away

Bonus:

- they're simpler and more cost-effective to develop


Once we extend "the properties" property to handle widgets uniformly 
with LC-engine-native controls, I'll gladly extend my 4W Prop Sheet to 
handle them, and even donate it to the project if they like so they 
won't have to lift a finger beyond providing the uniform access to prop 
arrays.




*If you haven't used an IDE with a property sheet, here's VB's as an 
example:

http://www.afralisp.net/visual-basic-for-applications/tutorials/images/vb-properties.png

--
 Richard Gaskin
 Fourth World Systems


Curry Kenworthy wrote:
As more client projects have caught up with 9, now I'm currently 
spending the majority of my time in LiveCode 9 IDE. That's both good and 
bad. The bad is that the 8/9 IDE's UI is much less efficient and much 
less polished than 6 was. And I'm starting to feel the cumulative impact 
of the less efficient and more tedious UI during my work! I like an 
efficient environment. That way I can get more work done in less time 
for my clients and addon users, and also train people how to accomplish 
tasks very easily in LC.


Some time ago I mentioned that the big IDE update was more of a 
downgrade, when it comes to UI and UX; way too many good things lost in 
the remake, very obvious to a hands-on user. But specifics were desired, 
and I didn't have any opportunity to focus on that until now when I'm 
dealing with these things daily while I work. So I'm starting to compile 
a big list of the current IDE defects. I will be filing QA report(s) on 
these soon. Obviously a big win-win for LC.


Posting here first, in case any of these are already filed (please let 
me know, I'll sign on) or anything to add.


I'm starting with the Property Inspector.

PI Fields:

- PI fields don't scroll with mouse scrollwheel. None of them do. 
(Sometimes the group containing them can do so, but that's not very 
well-designed or consistent either; more on that below.) Just paste or 
type more text than the field's current height, and then try the 
scrollwheel - nothing.


- PI Tooltip field is short, only one line high, can't resize unless you 
resize window or visit another tab and back. Window can't resize taller 
unless you visit another tab; tedious.


- Some PI fields are resized to their content height, but that causes 
side effects. If a field contains too much text, the window may be 
resized extremely short and when changing to other PI tabs, controls 
won't be shown until you resize the window again, but that doesn't 
always fix it permanently, more fiddling require as you change tabs. I 
suggest a better-planned approach to resize, not just fully maximizing 
the height of all fields, but either way it needs to work smoothly; 
that's the main thing. The PI is pretty important.


- Using tab key to cycle through fields, 9 PI usually places cursor at 
the start of the text, whereas 6 PI selected the entire text. Selecting 
the entire text was more efficient in most cases.


PI controls:

- Sometimes there is plenty of room horizontally for two columns, but 
the large empty horizontal space is not utilized, requiring a tall PI 
window.


- When we have little arrows and also a slider for the same value (such 
as Blend Level) it serves no purpose for slider click to increment by 1. 
Little arrows already do that. Those slider clicks should increment by 5 
or 10.


- When we have a slider with no field or arrows (such as Effects tab 
Drop shadow Color Opacity) we need more control and more info. There's 
no way to even tell what the current Opacity value is! Could be shown 
via field, tooltip, arrows ... something. Again here, the click 
increment by 1 doesn't seem very useful.


- Since effectFilter setting is no longer supported, should it show up 
in the UI? I would love to have it supported, that would be good for 
optimization, but otherwise there's no need to see it.


Custom Properties:

- Can't resize the Value field. And it doesn't accept the Tab key. 
(which was also imperfect in 6 but at least accepted.) No wrap control. 
Currently pretty useless for editing longer text.


- Faulty window resize. To test, resize to make the PI window very tall, 
then shorter again. 

Re: stackfiles

[Bob Sneidar via use-livecode]

> On Aug 9, 2018, at 08:07 , Klaus major-k via use-livecode 
>  wrote:
> 
> I mean if stack xyz has its stackfile property set, can other stack access 
> this property just like the stack xyz scripts?

If I understand you, then another stack can reference the stackfiles of xyz by 
getting the stackfiles of stack xyz. But I cannot think that is what you meant. 
The stackfiles is a property of a single stack, and not a global property. 

But I probably still do not understand. :-)

Bob S


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: stackfiles

[Klaus major-k via use-livecode]

Hi Bob,

> Am 09.08.2018 um 17:03 schrieb Bob Sneidar via use-livecode 
> :
> 
> I see, you are asking if the scripts of the stackfiles are inserted into the 
> message heirarchy? No. It can't work that way if you think about it. You 
> would never be able to include another stack in a standalone without having 
> every stack script of every stack in the message heirarchy. 

that's not not what I meant.

> If you are asking if the the script of stack xys is accessible to the stack 
> files however, then yes of course.

Not what I meant, I knew this before. 8-)

> If you are asking something else I cannot discern what it is. 

I mean if stack xyz has its stackfile property set, can other stack access this 
property just like the stack xyz scripts?

> Bob S
> 
> 
>> On Aug 9, 2018, at 07:53 , Klaus major-k via use-livecode 
>>  wrote:
>> 
>> Hi Bob,
>> 
>>> Am 09.08.2018 um 16:48 schrieb Bob Sneidar via use-livecode 
>>> :
>>> 
>>> Start Using simply inserts the script of that stack in the back, so it is 
>>> now in the message path which
>>> is global to everything running in that instance of livecode or the 
>>> standalone. 
>> 
>> yes, I know, this way it also lets other stacks us the "used" stacks 
>> external etc, but does this apply to STACKFILES, too? 
>> That was my question!

Best

Klaus

--
Klaus Major
http://www.major-k.de
kl...@major-k.de


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: stackfiles

[Bob Sneidar via use-livecode]

I see, you are asking if the scripts of the stackfiles are inserted into the 
message heirarchy? No. It can't work that way if you think about it. You would 
never be able to include another stack in a standalone without having every 
stack script of every stack in the message heirarchy. 

If you are asking if the the script of stack xys is accessible to the stack 
files however, then yes of course. If you are asking something else I cannot 
discern what it is. 

To my understanding, the stackfiles property simply makes it possible to 
reference stacks by their short names without having to reference their full 
paths when opening them. Also, when building a standalone, they will be 
included automatically. 

Bob S


> On Aug 9, 2018, at 07:53 , Klaus major-k via use-livecode 
>  wrote:
> 
> Hi Bob,
> 
>> Am 09.08.2018 um 16:48 schrieb Bob Sneidar via use-livecode 
>> :
>> 
>> Start Using simply inserts the script of that stack in the back, so it is 
>> now in the message path which
>> is global to everything running in that instance of livecode or the 
>> standalone. 
> 
> yes, I know, this way it also lets other stacks us the "used" stacks external 
> etc, but does this apply to STACKFILES, too? 
> That was my question!
> 


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Regaining IDE Efficiency: Property Inspector

[Bob Sneidar via use-livecode]

I'm using rc1, and the PI issues persist so far as I can see. As I mentioned, 
the element portion of the PI is actually a tree widget, so some of the issues 
are really with the tree widget, not the PI itself. 

Bob S


> On Aug 9, 2018, at 06:23 , Paul Dupuis via use-livecode 
>  wrote:
> 
> My understanding from something I (think I) saw on this list was that
> 9.0.1 is focused on IDE improvements. I have not yet downloaded 9.0.1rc
> (my bad) but can any others who have downloaded comment if the IDE, and
> PI in particular, is, in fact, improved? If so by how much (guestimate)?


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: stackfiles

[Klaus major-k via use-livecode]

Hi Bob,

> Am 09.08.2018 um 16:48 schrieb Bob Sneidar via use-livecode 
> :
> 
> Start Using simply inserts the script of that stack in the back, so it is now 
> in the message path which
> is global to everything running in that instance of livecode or the 
> standalone. 

yes, I know, this way it also lets other stacks us the "used" stacks external 
etc, but does this apply to STACKFILES, too? 
That was my question!

> Bob S
> 
>> On Aug 9, 2018, at 02:58 , Klaus major-k via use-livecode 
>>  wrote:
>> 
>> Hi friends,
>> 
>> quick question:
>> When I "start using stack xyz" then all stack can access the scripts etc.
>> of stack xyz. Does this also apply to the stackfiles of stack xyz?

Best

Klaus

--
Klaus Major
http://www.major-k.de
kl...@major-k.de


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Regaining IDE Efficiency: Property Inspector

[Bob Sneidar via use-livecode]

Oh never mind. PI (Property Inspector)

Bob S


> On Aug 9, 2018, at 07:51 , Bob Sneidar via use-livecode 
>  wrote:
> 
> if you insert cr's you get more lines. But a single line will not wrap. Not 
> sure tooltips in any version did. 
> 
> Bob S
> 
> 
>> On Aug 9, 2018, at 01:29 , Curry Kenworthy via use-livecode 
>>  wrote:
>> 
>> - PI Tooltip field is short, only one line high, can't resize unless you 
>> resize window or visit another tab and back. Window can't resize taller 
>> unless you visit another tab; tedious.
> 
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Regaining IDE Efficiency: Property Inspector

[Bob Sneidar via use-livecode]

if you insert cr's you get more lines. But a single line will not wrap. Not 
sure tooltips in any version did. 

Bob S


> On Aug 9, 2018, at 01:29 , Curry Kenworthy via use-livecode 
>  wrote:
> 
> - PI Tooltip field is short, only one line high, can't resize unless you 
> resize window or visit another tab and back. Window can't resize taller 
> unless you visit another tab; tedious.


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: stackfiles

[Bob Sneidar via use-livecode]

Start Using simply inserts the script of that stack in the back, so it is now 
in the message path which is global to everything running in that instance of 
livecode or the standalone. 

Bob S


> On Aug 9, 2018, at 02:58 , Klaus major-k via use-livecode 
>  wrote:
> 
> Hi friends,
> 
> quick question:
> When I "start using stack xyz" then all stack can access the scripts etc.
> of stack xyz. Does this also apply to the stackfiles of stack xyz?
> 
> Thanks in advance!
> 
> 
> Best
> 
> Klaus
> --
> Klaus Major
> http://www.major-k.de
> kl...@major-k.de


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: HTML to text in field

[Stephen MacLean via use-livecode]

Hi David,

I’m working on something thing similar at the moment (although I’m stripping 
out almost everything except for basic HTML formatting).

I too found that nugget by JLG and had the similar results. I’ve also looked at 
using XML and regex. The problem with HTML is that while it’s a standard, 
unless it’s strict xHtml, it’s not really and a lot of it ends up being 
malformed, etc. Todays browsers are very forgiving and figure most of it out, 
but if you open the dev tools in safari or firefox and look at most pages, you 
will see a LOT of errors.

So I don’t think there is an “out of the box” answer. My solution is similar to 
what you are trying, stripping out tags and some other things and cleaning it 
up to give me what I want.

If your solution (after fixing the function vs command syntax that Klaus 
pointed out) doesn’t work for you, I could put together an example stack using 
my “cleaner” to share. I don’t claim it’s the best, only or anything else way 
to do it, other than it works for me and am happy to share.

Best,

Steve MacLean

> On Aug 9, 2018, at 8:00 AM, David V Glasgow via use-livecode 
>  wrote:
> 
> Hello folks,
> 
> I am having an interesting time (MacOS 10.13.5 LC 8.1.9) trying to load some 
> HTML files (≤ 5 ish MB).  Most of them will be lists or tables, generated by 
> various users on various systems.
> 
> I don’t want to retain any of the formatting, except line endings, so I would 
> be happy for tables to appear as lists.  I found a little 2013 nugget from 
> the estimable  Jacqueline Landman Gay
> 
> set the htmltext of the templatefield to htmlVar -- variable contains the 
> html string
> put the text of the templatefield into tPlainText
> 
> In some cases that works fine, but in others, it seems that HTML tables 
> consisting  of maybe 20-30 thousand rows are rendered onto a single line of 
> the field.  A sort of black-letters-overwritten splodge appears in the first 
> row and LC cranks up to 100% of the processor and BBoD ensues.
> 
> Sometimes it never seems to recover, but other times it hands back control 
> after maybe 20 minutes or so, and in those cases I can see the text if I set 
> dontwrap to false.  It contains no line endings from the original table, and 
> a shedload of tabs.
> 
> I have tried to operate on the HTML string in a variable before putting it 
> into the field, but frankly don’t really know what property of some HTML 
> tables might mean that line endings are lost.  I can only see  when I 
> examine the files in an editor.  
> 
> I tried a different approach, replacing a row end with a cr, and then 
> stripping out tags:
> 
> put URL ("file:" & theFilePath) into ttemp
> 
> replace "" with cr in ttemp
> 
> replaceText (ttemp, "<*>", "|")
> 
> filter lines of ttemp without empty
> 
> set the text of field "import" to ttemp
> 
> 
> The replaceText line generates an error “button "Import HTML": execution 
> error at line 7 (Handler: can't find handler) near "replaceText", char 1”  
> 
> Firstly I don’t get the error, and secondly I am worried I may be over 
> complicating something which should be simple.
> 
> Advice please!
> 
> Best wishes,
> 
> David Glasgow
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: How to get LiveCode to return 'Today' & 'Now'?

[Keith Clarke via use-livecode]

Thanks Brian (& Tore) - a brain-fade meant I clearly forgot ‘the obvious’ 
syntax  :-)

Best,
Keith

> On 9 Aug 2018, at 14:57, Brian Milby via use-livecode 
>  wrote:
> 
> the date
> the time
> 
> Thanks,
> Brian
> On Aug 9, 2018, 8:56 AM -0500, Keith Clarke via use-livecode 
> , wrote:
>> Hi folks,
>> Please can anyone share the magic syntax to
>> 
>> put today into tDate
>> 
>> put now into the tTime
>> 
>> I haven’t found a magic keyword to seed the docs or Google.
>> Thanks
>> Keith
>> ___
>> use-livecode mailing list
>> use-livecode@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your subscription 
>> preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Tutorial for MAP widget

[Klaus major-k via use-livecode]

Hi all,

could someone (the mothership?) please create a little tuorial
for the new MAP widget? This is really not self-explaining.
How to let the user create a new marker etc...

Thanks a lot!


Best

Klaus
--
Klaus Major
http://www.major-k.de
kl...@major-k.de


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: How to get LiveCode to return 'Today' & 'Now'?

[Tore Nilsen via use-livecode]

Use any form of the date (short, long,international,system) for today, an any 
form of the time  (short, long,international,system) for the time. To see the 
difference between them look them up in the dictionary.


Regards
Tore Nilsen

---
This mail contains no viruses or bacteria as it is electronically produced and 
untouched by human hands. Once printed it may or may not contain various 
microorganisms that can cause diseases. Print and hand out at own risk. 
Unsolicited distribution of this mail is prohibited.







> 09. aug. 2018 kl. 15:55 skrev Keith Clarke via use-livecode 
> :
> 
> Hi folks,
> Please can anyone share the magic syntax to  
> 
> put today into tDate  
> 
> put now into the tTime
> 
> I haven’t found a magic keyword to seed the docs or Google.
> Thanks
> Keith  
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: How to get LiveCode to return 'Today' & 'Now'?

[Brian Milby via use-livecode]

the date
the time

Thanks,
Brian
On Aug 9, 2018, 8:56 AM -0500, Keith Clarke via use-livecode 
, wrote:
> Hi folks,
> Please can anyone share the magic syntax to
>
> put today into tDate
>
> put now into the tTime
>
> I haven’t found a magic keyword to seed the docs or Google.
> Thanks
> Keith
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

How to get LiveCode to return 'Today' & 'Now'?

[Keith Clarke via use-livecode]

Hi folks,
Please can anyone share the magic syntax to  

put today into tDate  

put now into the tTime

I haven’t found a magic keyword to seed the docs or Google.
Thanks
Keith  
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: HTML to text in field

[David V Glasgow via use-livecode]

D’OH!

> On 9 Aug 2018, at 2:23 pm, Klaus major-k via use-livecode 
>  wrote:
> 
> 
> "replacetext ()" is a FUNCTION and not a handler! :-)

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Regaining IDE Efficiency: Property Inspector

[Tom Glod via use-livecode]

great breakdown of the issues.. i have been ramping up tp sit down and
make all those notes. its hard to do when you go work to do.  So thanks
Curry for going through that.

Once these are fixed, I think the IDE will be quite good.


On Thu, Aug 9, 2018 at 9:23 AM, Paul Dupuis via use-livecode <
use-livecode@lists.runrev.com> wrote:

> I second Curry's list of LC 9.0.0 IDE issue - especially when the PI
> resizes itself switching between tabs to cut off display of fields below
> the current window size.
>
> My understanding from something I (think I) saw on this list was that
> 9.0.1 is focused on IDE improvements. I have not yet downloaded 9.0.1rc
> (my bad) but can any others who have downloaded comment if the IDE, and
> PI in particular, is, in fact, improved? If so by how much (guestimate)?
>
>
> On 8/9/2018 4:29 AM, Curry Kenworthy via use-livecode wrote:
> >
> > Howdy Folks,
> >
> > As more client projects have caught up with 9, now I'm currently
> > spending the majority of my time in LiveCode 9 IDE. That's both good
> > and bad. The bad is that the 8/9 IDE's UI is much less efficient and
> > much less polished than 6 was. And I'm starting to feel the cumulative
> > impact of the less efficient and more tedious UI during my work! I
> > like an efficient environment. That way I can get more work done in
> > less time for my clients and addon users, and also train people how to
> > accomplish tasks very easily in LC.
> >
> > Some time ago I mentioned that the big IDE update was more of a
> > downgrade, when it comes to UI and UX; way too many good things lost
> > in the remake, very obvious to a hands-on user. But specifics were
> > desired, and I didn't have any opportunity to focus on that until now
> > when I'm dealing with these things daily while I work. So I'm starting
> > to compile a big list of the current IDE defects. I will be filing QA
> > report(s) on these soon. Obviously a big win-win for LC.
> >
> > Posting here first, in case any of these are already filed (please let
> > me know, I'll sign on) or anything to add.
> >
> > I'm starting with the Property Inspector.
> >
> > PI Fields:
> >
> > - PI fields don't scroll with mouse scrollwheel. None of them do.
> > (Sometimes the group containing them can do so, but that's not very
> > well-designed or consistent either; more on that below.) Just paste or
> > type more text than the field's current height, and then try the
> > scrollwheel - nothing.
> >
> > - PI Tooltip field is short, only one line high, can't resize unless
> > you resize window or visit another tab and back. Window can't resize
> > taller unless you visit another tab; tedious.
> >
> > - Some PI fields are resized to their content height, but that causes
> > side effects. If a field contains too much text, the window may be
> > resized extremely short and when changing to other PI tabs, controls
> > won't be shown until you resize the window again, but that doesn't
> > always fix it permanently, more fiddling require as you change tabs. I
> > suggest a better-planned approach to resize, not just fully maximizing
> > the height of all fields, but either way it needs to work smoothly;
> > that's the main thing. The PI is pretty important.
> >
> > - Using tab key to cycle through fields, 9 PI usually places cursor at
> > the start of the text, whereas 6 PI selected the entire text.
> > Selecting the entire text was more efficient in most cases.
> >
> > PI controls:
> >
> > - Sometimes there is plenty of room horizontally for two columns, but
> > the large empty horizontal space is not utilized, requiring a tall PI
> > window.
> >
> > - When we have little arrows and also a slider for the same value
> > (such as Blend Level) it serves no purpose for slider click to
> > increment by 1. Little arrows already do that. Those slider clicks
> > should increment by 5 or 10.
> >
> > - When we have a slider with no field or arrows (such as Effects tab
> > Drop shadow Color Opacity) we need more control and more info. There's
> > no way to even tell what the current Opacity value is! Could be shown
> > via field, tooltip, arrows ... something. Again here, the click
> > increment by 1 doesn't seem very useful.
> >
> > - Since effectFilter setting is no longer supported, should it show up
> > in the UI? I would love to have it supported, that would be good for
> > optimization, but otherwise there's no need to see it.
> >
> > Custom Properties:
> >
> > - Can't resize the Value field. And it doesn't accept the Tab key.
> > (which was also imperfect in 6 but at least accepted.) No wrap
> > control. Currently pretty useless for editing longer text.
> >
> > - Faulty window resize. To test, resize to make the PI window very
> > tall, then shorter again. The element list always gets taller with the
> > window, but never contracts again, even when there's only 1 element,
> > so it becomes ridiculously big and the Key and Value fields are no
> > longer in view without scrolling.
> >
> > - 

Re: HTML to text in field

[Richard Gaskin via use-livecode]

Richmond Mathewson wrote:

>put (URL ("file:" & it),"UTF8") into CHEESE

Was uniDecode intended there?

--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Regaining IDE Efficiency: Property Inspector

[Paul Dupuis via use-livecode]

I second Curry's list of LC 9.0.0 IDE issue - especially when the PI
resizes itself switching between tabs to cut off display of fields below
the current window size.

My understanding from something I (think I) saw on this list was that
9.0.1 is focused on IDE improvements. I have not yet downloaded 9.0.1rc
(my bad) but can any others who have downloaded comment if the IDE, and
PI in particular, is, in fact, improved? If so by how much (guestimate)?


On 8/9/2018 4:29 AM, Curry Kenworthy via use-livecode wrote:
>
> Howdy Folks,
>
> As more client projects have caught up with 9, now I'm currently
> spending the majority of my time in LiveCode 9 IDE. That's both good
> and bad. The bad is that the 8/9 IDE's UI is much less efficient and
> much less polished than 6 was. And I'm starting to feel the cumulative
> impact of the less efficient and more tedious UI during my work! I
> like an efficient environment. That way I can get more work done in
> less time for my clients and addon users, and also train people how to
> accomplish tasks very easily in LC.
>
> Some time ago I mentioned that the big IDE update was more of a
> downgrade, when it comes to UI and UX; way too many good things lost
> in the remake, very obvious to a hands-on user. But specifics were
> desired, and I didn't have any opportunity to focus on that until now
> when I'm dealing with these things daily while I work. So I'm starting
> to compile a big list of the current IDE defects. I will be filing QA
> report(s) on these soon. Obviously a big win-win for LC.
>
> Posting here first, in case any of these are already filed (please let
> me know, I'll sign on) or anything to add.
>
> I'm starting with the Property Inspector.
> 
> PI Fields:
>
> - PI fields don't scroll with mouse scrollwheel. None of them do.
> (Sometimes the group containing them can do so, but that's not very
> well-designed or consistent either; more on that below.) Just paste or
> type more text than the field's current height, and then try the
> scrollwheel - nothing.
>
> - PI Tooltip field is short, only one line high, can't resize unless
> you resize window or visit another tab and back. Window can't resize
> taller unless you visit another tab; tedious.
>
> - Some PI fields are resized to their content height, but that causes
> side effects. If a field contains too much text, the window may be
> resized extremely short and when changing to other PI tabs, controls
> won't be shown until you resize the window again, but that doesn't
> always fix it permanently, more fiddling require as you change tabs. I
> suggest a better-planned approach to resize, not just fully maximizing
> the height of all fields, but either way it needs to work smoothly;
> that's the main thing. The PI is pretty important.
>
> - Using tab key to cycle through fields, 9 PI usually places cursor at
> the start of the text, whereas 6 PI selected the entire text.
> Selecting the entire text was more efficient in most cases.
>
> PI controls:
>
> - Sometimes there is plenty of room horizontally for two columns, but
> the large empty horizontal space is not utilized, requiring a tall PI
> window.
>
> - When we have little arrows and also a slider for the same value
> (such as Blend Level) it serves no purpose for slider click to
> increment by 1. Little arrows already do that. Those slider clicks
> should increment by 5 or 10.
>
> - When we have a slider with no field or arrows (such as Effects tab
> Drop shadow Color Opacity) we need more control and more info. There's
> no way to even tell what the current Opacity value is! Could be shown
> via field, tooltip, arrows ... something. Again here, the click
> increment by 1 doesn't seem very useful.
>
> - Since effectFilter setting is no longer supported, should it show up
> in the UI? I would love to have it supported, that would be good for
> optimization, but otherwise there's no need to see it.
>
> Custom Properties:
>
> - Can't resize the Value field. And it doesn't accept the Tab key.
> (which was also imperfect in 6 but at least accepted.) No wrap
> control. Currently pretty useless for editing longer text.
>
> - Faulty window resize. To test, resize to make the PI window very
> tall, then shorter again. The element list always gets taller with the
> window, but never contracts again, even when there's only 1 element,
> so it becomes ridiculously big and the Key and Value fields are no
> longer in view without scrolling.
>
> - Value field bug or critical flaw: it is or was easy to lose changes
> when editing the Value of a prop if you click in the wrong place. Now
> it seems better testing this time in 901rc1; this may have been fixed
> already?
>
> - Inefficient when adding new element, requires extra click from user
> to select the newly added element, another extra click to select the
> name. Clicks matter! It could be already opened for editing after
> creation, with the entire Key field text selected. Or just use the ask
> dialog as 

Re: HTML to text in field

[Klaus major-k via use-livecode]

Hi David,

> Am 09.08.2018 um 15:21 schrieb David V Glasgow via use-livecode 
> :
> 
> Thanks Richmond, I will mess about with your suggestions.  It's always much 
> appreciated when someone takes the time to suggest a complete handler.
> But …. I want more!  Can you see anything wrong with this?
> 
> replaceText (ttemp, "<*>", "|")
> or have a clue about the error message? 
> “button "Import HTML": execution error at line 7 (Handler: can't find 
> handler) near "replaceText", char 1”

"replacetext ()" is a FUNCTION and not a handler! :-)

> Cheers,
> 
> David G

Best

Klaus

--
Klaus Major
http://www.major-k.de
kl...@major-k.de


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: HTML to text in field

[David V Glasgow via use-livecode]

Thanks Richmond, I will mess about with your suggestions.  It's always much 
appreciated when someone takes the time to suggest a complete handler.

But …. I want more!  Can you see anything wrong with this?


replaceText (ttemp, "<*>", "|")

or have a clue about the error message? 

 “button "Import HTML": execution error at line 7 (Handler: can't find handler) 
near "replaceText", char 1”

Cheers,

David G
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: HTML to text in field

[Richmond Mathewson via use-livecode]

Well, although this might sound a bit goofy,
how about just bunging your html text into a scrolling list field and 
every time you

came across a  moving down to a new line?

This works:

on mouseUp
   set the text of fld "SLF1" to empty
answer file "Choose an HTML file to import"
   if the result = "cancel"
   then exit mouseUp
   else
  put (URL ("file:" & it),"UTF8") into CHEESE
   end if
   put 1 into LYNE
   repeat until CHEESE is empty
  if word 1 of CHEESE is "" then
 add 1 to LYNE
 delete word 1 of CHEESE
 else
put word 1 of CHEESE after line LYNE of fld "SLF1"
delete word 1 of CHEESE
end if
   end repeat
end mouseUp

where fld "SLF1" is a scrolling list field.

Admittedly it makes a pig's breakfast out of everything else.

Richmond.



On 9/8/2018 3:00 pm, David V Glasgow via use-livecode wrote:

Hello folks,

I am having an interesting time (MacOS 10.13.5 LC 8.1.9) trying to load some 
HTML files (≤ 5 ish MB).  Most of them will be lists or tables, generated by 
various users on various systems.

I don’t want to retain any of the formatting, except line endings, so I would 
be happy for tables to appear as lists.  I found a little 2013 nugget from the 
estimable  Jacqueline Landman Gay

set the htmltext of the templatefield to htmlVar -- variable contains the html 
string
put the text of the templatefield into tPlainText

In some cases that works fine, but in others, it seems that HTML tables 
consisting  of maybe 20-30 thousand rows are rendered onto a single line of the 
field.  A sort of black-letters-overwritten splodge appears in the first row 
and LC cranks up to 100% of the processor and BBoD ensues.

Sometimes it never seems to recover, but other times it hands back control 
after maybe 20 minutes or so, and in those cases I can see the text if I set 
dontwrap to false.  It contains no line endings from the original table, and a 
shedload of tabs.

I have tried to operate on the HTML string in a variable before putting it into the 
field, but frankly don’t really know what property of some HTML tables might mean 
that line endings are lost.  I can only see  when I examine the files in 
an editor.

I tried a different approach, replacing a row end with a cr, and then stripping 
out tags:

put URL ("file:" & theFilePath) into ttemp

replace "" with cr in ttemp

replaceText (ttemp, "<*>", "|")

filter lines of ttemp without empty

set the text of field "import" to ttemp


The replaceText line generates an error “button "Import HTML": execution error at line 7 
(Handler: can't find handler) near "replaceText", char 1”

Firstly I don’t get the error, and secondly I am worried I may be over 
complicating something which should be simple.

Advice please!

Best wishes,

David Glasgow
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

HTML to text in field

[David V Glasgow via use-livecode]

Hello folks,

I am having an interesting time (MacOS 10.13.5 LC 8.1.9) trying to load some 
HTML files (≤ 5 ish MB).  Most of them will be lists or tables, generated by 
various users on various systems.

I don’t want to retain any of the formatting, except line endings, so I would 
be happy for tables to appear as lists.  I found a little 2013 nugget from the 
estimable  Jacqueline Landman Gay

set the htmltext of the templatefield to htmlVar -- variable contains the html 
string
put the text of the templatefield into tPlainText

In some cases that works fine, but in others, it seems that HTML tables 
consisting  of maybe 20-30 thousand rows are rendered onto a single line of the 
field.  A sort of black-letters-overwritten splodge appears in the first row 
and LC cranks up to 100% of the processor and BBoD ensues.

Sometimes it never seems to recover, but other times it hands back control 
after maybe 20 minutes or so, and in those cases I can see the text if I set 
dontwrap to false.  It contains no line endings from the original table, and a 
shedload of tabs.

I have tried to operate on the HTML string in a variable before putting it into 
the field, but frankly don’t really know what property of some HTML tables 
might mean that line endings are lost.  I can only see  when I examine the 
files in an editor.  

I tried a different approach, replacing a row end with a cr, and then stripping 
out tags:

put URL ("file:" & theFilePath) into ttemp

replace "" with cr in ttemp

replaceText (ttemp, "<*>", "|")

filter lines of ttemp without empty

set the text of field "import" to ttemp


The replaceText line generates an error “button "Import HTML": execution error 
at line 7 (Handler: can't find handler) near "replaceText", char 1”  

Firstly I don’t get the error, and secondly I am worried I may be over 
complicating something which should be simple.

Advice please!

Best wishes,

David Glasgow
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Intersect outputs different result in desktop and LC server

[Alex Tweedly via use-livecode]

I sent a support request asking for it :-)

AFAIK, at least on sage, it is installed systemwide - so any file with 
extension .lc9 will use the latest stable release of LC9 (this is a 
similar scheme to what HostM use).


I suspect you can use .htaccess to ensure it is used for all .lc files, 
but I didn't do that; I kept all the old stuff unchanged, and use the 
.lc9 extension in the two files I need it (they then load other 
.livecodescript libraries, and some other .lc files, so I got all my old 
functionality by renaming these two files, and redirecting a couple of 
URLs).


-- Alex.


On 09/08/2018 06:52, jbv via use-livecode wrote:

How do you run LC9 server on on-rev ?
Thanks.


On Thu, August 9, 2018 1:40 am, Alex Tweedly via use-livecode wrote:

Oops - sent before I meant to ...


With LC7 server on on-rev, I get


4141 5378 18699 28365 41200 50230 58901 62983 63416 65984 71574 73426
74288 112360 115826 121386 126039 141224


while with LC9 server on on-rev I get

4141


-- Alex.








___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

stackfiles

[Klaus major-k via use-livecode]

Hi friends,

quick question:
When I "start using stack xyz" then all stack can access the scripts etc.
of stack xyz. Does this also apply to the stackfiles of stack xyz?

Thanks in advance!


Best

Klaus
--
Klaus Major
http://www.major-k.de
kl...@major-k.de


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Regaining IDE Efficiency: Property Inspector

[Curry Kenworthy via use-livecode]

Howdy Folks,

As more client projects have caught up with 9, now I'm currently 
spending the majority of my time in LiveCode 9 IDE. That's both good and 
bad. The bad is that the 8/9 IDE's UI is much less efficient and much 
less polished than 6 was. And I'm starting to feel the cumulative impact 
of the less efficient and more tedious UI during my work! I like an 
efficient environment. That way I can get more work done in less time 
for my clients and addon users, and also train people how to accomplish 
tasks very easily in LC.


Some time ago I mentioned that the big IDE update was more of a 
downgrade, when it comes to UI and UX; way too many good things lost in 
the remake, very obvious to a hands-on user. But specifics were desired, 
and I didn't have any opportunity to focus on that until now when I'm 
dealing with these things daily while I work. So I'm starting to compile 
a big list of the current IDE defects. I will be filing QA report(s) on 
these soon. Obviously a big win-win for LC.


Posting here first, in case any of these are already filed (please let 
me know, I'll sign on) or anything to add.


I'm starting with the Property Inspector.

PI Fields:

- PI fields don't scroll with mouse scrollwheel. None of them do. 
(Sometimes the group containing them can do so, but that's not very 
well-designed or consistent either; more on that below.) Just paste or 
type more text than the field's current height, and then try the 
scrollwheel - nothing.


- PI Tooltip field is short, only one line high, can't resize unless you 
resize window or visit another tab and back. Window can't resize taller 
unless you visit another tab; tedious.


- Some PI fields are resized to their content height, but that causes 
side effects. If a field contains too much text, the window may be 
resized extremely short and when changing to other PI tabs, controls 
won't be shown until you resize the window again, but that doesn't 
always fix it permanently, more fiddling require as you change tabs. I 
suggest a better-planned approach to resize, not just fully maximizing 
the height of all fields, but either way it needs to work smoothly; 
that's the main thing. The PI is pretty important.


- Using tab key to cycle through fields, 9 PI usually places cursor at 
the start of the text, whereas 6 PI selected the entire text. Selecting 
the entire text was more efficient in most cases.


PI controls:

- Sometimes there is plenty of room horizontally for two columns, but 
the large empty horizontal space is not utilized, requiring a tall PI 
window.


- When we have little arrows and also a slider for the same value (such 
as Blend Level) it serves no purpose for slider click to increment by 1. 
Little arrows already do that. Those slider clicks should increment by 5 
or 10.


- When we have a slider with no field or arrows (such as Effects tab 
Drop shadow Color Opacity) we need more control and more info. There's 
no way to even tell what the current Opacity value is! Could be shown 
via field, tooltip, arrows ... something. Again here, the click 
increment by 1 doesn't seem very useful.


- Since effectFilter setting is no longer supported, should it show up 
in the UI? I would love to have it supported, that would be good for 
optimization, but otherwise there's no need to see it.


Custom Properties:

- Can't resize the Value field. And it doesn't accept the Tab key. 
(which was also imperfect in 6 but at least accepted.) No wrap control. 
Currently pretty useless for editing longer text.


- Faulty window resize. To test, resize to make the PI window very tall, 
then shorter again. The element list always gets taller with the window, 
but never contracts again, even when there's only 1 element, so it 
becomes ridiculously big and the Key and Value fields are no longer in 
view without scrolling.


- Value field bug or critical flaw: it is or was easy to lose changes 
when editing the Value of a prop if you click in the wrong place. Now it 
seems better testing this time in 901rc1; this may have been fixed already?


- Inefficient when adding new element, requires extra click from user to 
select the newly added element, another extra click to select the name. 
Clicks matter! It could be already opened for editing after creation, 
with the entire Key field text selected. Or just use the ask dialog as 
before.


- Easy to confuse the "Add Array Key" "+" buttons with adding a new 
element, and that's fine to learn, but even after you learn it, it's 
still easy to click by accident. Then there's trouble; if you didn't 
want an array, the problem is that you've permanently lost the original 
Value for that key. That may be a big important text that is nontrivial 
to lose with a single click! Prop values are important. Possible fix by 
putting the original value into the value for the newly created 
subelement when changing a single element into an array.


PI window and tabs:

- The PI tabs (Basic, Contents,