Re: Documentation on Low Level Database Access

[Dalton Calford via use-livecode]

Hi Mark,

If I remember correctly, wasn't that DB-Layer rewrite promed back in
version 5 or 6 along with full support for version control?

On Thu, 11 Apr 2019 at 16:09, Mark Wieder via use-livecode <
use-livecode@lists.runrev.com> wrote:

> On 4/11/19 9:12 AM, Dalton Calford via use-livecode wrote:
> > Hi all,
> >
> > I am looking at the git repositories, the widget documentation etc.,
> > looking for a solid guide on how livecode accesses database engines.
> >
> > For example, if I wanted to add low level support for another open source
> > database that is available on all the same platforms as livecode, is
> there
> > any documentation/standardization that I can follow?
>
> Having started down that road some years ago and run into some immense
> walls (i.e., an external library that had to be static and dynamic at
> the same time), I backed off in favor of waiting for the fabled db layer
> rewrite that was just around the corner. Still waiting.
>
> --
>   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
>
___
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: Debugging in iOS 12?

[William Prothero via use-livecode]

Thanks, Ralph!
Bill

> On Apr 11, 2019, at 2:04 PM, Ralph DiMola via use-livecode 
>  wrote:
> 
> That 10.1 error message will not affect your development. You can still drag 
> apps into the devices window. You can also have both 10.1 and 10.2 on your 
> Mac. Use 10.1 for building iOS apps and run 10.2 to access the devices 
> window. If you have both versions then use 10.1 in the LC prefs. From the 
> command prompt you can set the version of the tools that LC will use for 
> building.
> 
> 2 commands
> 1) (xcode-select --print-path) will display the version in use
> 2) (sudu xcode-select -switch "path/to/xcode.app") will set the build tools 
> version
> 
> I keep multiple version of Xcode in a separate folder so I can use older 
> simulators.
> 
> Ralph DiMola
> IT Director
> Evergreen Information Services
> rdim...@evergreeninfo.net
> 
> -Original Message-
> From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf 
> Of William Prothero via use-livecode
> Sent: Thursday, April 11, 2019 4:38 PM
> To: Use-livecode Use-livecode
> Cc: William Prothero
> Subject: Debugging in iOS 12?
> 
> Folks:
> I’m just diving into debugging my iPhone app after a long hiatus. I have iOS 
> 12.2 on my iPhone and am using Xcode 10.1. Unfortunately, it appears that LC 
> 9.0.4 (rc2) won’t support Xcode 10.2 (from the web site) and I get the 
> following error message in Xcode:
> 
> "This iPhone 6 is running iOS 12.2 (16E227), which may not be supported by 
> this version of Xcode.”
> 
> Is there anything I can do except wait for the next version of livecode to 
> come out? I should have waited to update my iOS version. Arg! Such a pain to 
> wade into this thicket of provisions, certificates, etc. again. At least 
> there are more support docs from Livecode.
> 
> Any advice would be welcomed.
> 
> Best,
> Bill
> 
> William A. Prothero
> http://earthlearningsolutions.org
> 
> ___
> 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: Debugging in iOS 12?

[Ralph DiMola via use-livecode]

That 10.1 error message will not affect your development. You can still drag 
apps into the devices window. You can also have both 10.1 and 10.2 on your Mac. 
Use 10.1 for building iOS apps and run 10.2 to access the devices window. If 
you have both versions then use 10.1 in the LC prefs. From the command prompt 
you can set the version of the tools that LC will use for building.

2 commands
1) (xcode-select --print-path) will display the version in use
2) (sudu xcode-select -switch "path/to/xcode.app") will set the build tools 
version

I keep multiple version of Xcode in a separate folder so I can use older 
simulators.

Ralph DiMola
IT Director
Evergreen Information Services
rdim...@evergreeninfo.net

-Original Message-
From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf Of 
William Prothero via use-livecode
Sent: Thursday, April 11, 2019 4:38 PM
To: Use-livecode Use-livecode
Cc: William Prothero
Subject: Debugging in iOS 12?

Folks:
I’m just diving into debugging my iPhone app after a long hiatus. I have iOS 
12.2 on my iPhone and am using Xcode 10.1. Unfortunately, it appears that LC 
9.0.4 (rc2) won’t support Xcode 10.2 (from the web site) and I get the 
following error message in Xcode:

"This iPhone 6 is running iOS 12.2 (16E227), which may not be supported by this 
version of Xcode.”

Is there anything I can do except wait for the next version of livecode to come 
out? I should have waited to update my iOS version. Arg! Such a pain to wade 
into this thicket of provisions, certificates, etc. again. At least there are 
more support docs from Livecode.

Any advice would be welcomed.

Best,
Bill

William A. Prothero
http://earthlearningsolutions.org

___
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

Debugging in iOS 12?

[William Prothero via use-livecode]

Folks:
I’m just diving into debugging my iPhone app after a long hiatus. I have iOS 
12.2 on my iPhone and am using Xcode 10.1. Unfortunately, it appears that LC 
9.0.4 (rc2) won’t support Xcode 10.2 (from the web site) and I get the 
following error message in Xcode:

"This iPhone 6 is running iOS 12.2 (16E227), which may not be supported by this 
version of Xcode.”

Is there anything I can do except wait for the next version of livecode to come 
out? I should have waited to update my iOS version. Arg! Such a pain to wade 
into this thicket of provisions, certificates, etc. again. At least there are 
more support docs from Livecode.

Any advice would be welcomed.

Best,
Bill

William A. Prothero
http://earthlearningsolutions.org

___
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: Panel/Form Widget

[Richard Gaskin via use-livecode]

Dalton Calford wrote:

> I was about to explain using screen shots, flow diagrams etc., but,
> then I thought this may not be the best place to be discussing this.
>
> If you think this is as good a list as any, I can proceed, but, I will
> have to do so later this evening as I am about to start a MOP.

If this relates to what is known in the xTalk world as Viewers (we could 
call it other things, but the concept being viewing a stack within 
another stack), that would seem of enough general interest to keep it here.


If it's about something more obscure, it may still be useful here as 
such things can be easily filtered/ignored by those not interested in 
them, while allowing those who are interested to follow along without 
needing to hunt down wherever the conversation may have been moved to.


--
 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: Documentation on Low Level Database Access

[Mark Wieder via use-livecode]

On 4/11/19 9:12 AM, Dalton Calford via use-livecode wrote:

Hi all,

I am looking at the git repositories, the widget documentation etc.,
looking for a solid guide on how livecode accesses database engines.

For example, if I wanted to add low level support for another open source
database that is available on all the same platforms as livecode, is there
any documentation/standardization that I can follow?


Having started down that road some years ago and run into some immense 
walls (i.e., an external library that had to be static and dynamic at 
the same time), I backed off in favor of waiting for the fabled db layer 
rewrite that was just around the corner. Still waiting.


--
 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

Best strategy for dragging objects in an out of groups?

[Michael Kristensen via use-livecode]

Hi there

What would be the best strategy for dragging objects in and out of groups?

If anyone has a stack that demonstrate that it would be nice

else

just explain in plain words what you think is the best strategy.


Thanks
Michael

PS While I write this Im thinking that maybe RELAYER in a mouseMove handler 
could be used.
___
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: Panel/Form Widget

[Dalton Calford via use-livecode]

I was about to explain using screen shots, flow diagrams etc., but, then I
thought this may not be the best place to be discussing this.

If you think this is as good a list as any, I can proceed, but, I will have
to do so later this evening as I am about to start a MOP.

best regards

Dalton

On Thu, 11 Apr 2019 at 15:44, Richard Gaskin via use-livecode <
use-livecode@lists.runrev.com> wrote:

> This is a very interesting description of a graph database application.
>
> But how does it relate to having a stack viewable within another stack?
>
> --
>   Richard Gaskin
>   Fourth World Systems
>
>
> Dalton Calford wrote:
>
> > ok,
> >
> > In order to explain what I need the utility for, is as a front end to a
> > highly normalized warehouse Temporal Graph database.
> > That probably means nothing to you, but, lets assume it does for the time
> > being.
> >
> > For a simple example, lets say we are dealing with addresses, 2.6 billion
> > addresses, along with geo location.
> > The database does not contain nulls, data tuple width is variable based
> > upon a recursive multi-parent relationship.
> > Language/Locale information is part of the data structure
> > The client connects to a local embedded database which only is used for
> > work que's and caching and it in turn will connect to the middle tiers
> for
> > data synchronization/load balancing
> > Authentication is a round robin authkey token passed between the various
> > layers over an encrypted database to database channel.
> >
> > (no, this is not star trek technobabble, it is actually a 1' summary
> of
> > a specification)
> >
> > For discussions sake, lets agree upon some terms.
> >
> > *Viewers* is not natural to me as I never heard the term used before this
> > discussion.   Lets use a different term
> >
> > *DataPanel :- *This is the ultimate goal.
> >
> >
> > Ok, in order to explain what is going on, lets begin with a description
> of
> > a data warehouse problem.
> >
> > A simple address.
> >
> > An address has multiple elements, almost all of them defined identically
> -
> > a text string.   Depending upon your location on the planet, the details
> > are very different.   You could have street numbers or a building number
> > within a block.   You can have rural or municipal addresses etc.   Not
> all
> > address fields are needed for every address, and you do not want a single
> > null (undefined data) in the database.
> > So, in order to handle this, each address has a unique id, this is the
> > master link.   That master link is also linked to a definition of fields
> > that comprise this particular address.So, the first address is
> [street
> > number][street name] while the second is [plot number][rural road
> > number][municipality].So two addresses, in the same table, with
> totally
> > different columns.   You can add columns to the addresses on the fly, you
> > can even self populate the columns (surface them) based upon postal code.
> > Now, this is a full discussion on its own, but, it makes data very easy
> to
> > manage.
> > For example, lets say, you have 100 addresses, each address is in one
> city,
> > that city is in a state and that state is in a country.
> > Each one of those addresses would have a pointer to the city, which has a
> > pointer to the state, which has a pointer to the country.
> > So, you only ever have the country entered once in the database (with a
> > list of how it is used in various languages), same with state and city.
> >  This cuts the total size of the database enormously.
> >
> > In order to handle a situation like this, you need a series of embedded
> > datapanels.
> >
> > hmmm, I am thinking this may be very boring for the majority of people on
> > this list, perhaps there is a better list than 'using livecode' for this
> > discussion?
>
>
> ___
> 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: Panel/Form Widget

[Richard Gaskin via use-livecode]

This is a very interesting description of a graph database application.

But how does it relate to having a stack viewable within another stack?

--
 Richard Gaskin
 Fourth World Systems


Dalton Calford wrote:


ok,

In order to explain what I need the utility for, is as a front end to a
highly normalized warehouse Temporal Graph database.
That probably means nothing to you, but, lets assume it does for the time
being.

For a simple example, lets say we are dealing with addresses, 2.6 billion
addresses, along with geo location.
The database does not contain nulls, data tuple width is variable based
upon a recursive multi-parent relationship.
Language/Locale information is part of the data structure
The client connects to a local embedded database which only is used for
work que's and caching and it in turn will connect to the middle tiers for
data synchronization/load balancing
Authentication is a round robin authkey token passed between the various
layers over an encrypted database to database channel.

(no, this is not star trek technobabble, it is actually a 1' summary of
a specification)

For discussions sake, lets agree upon some terms.

*Viewers* is not natural to me as I never heard the term used before this
discussion.   Lets use a different term

*DataPanel :- *This is the ultimate goal.


Ok, in order to explain what is going on, lets begin with a description of
a data warehouse problem.

A simple address.

An address has multiple elements, almost all of them defined identically -
a text string.   Depending upon your location on the planet, the details
are very different.   You could have street numbers or a building number
within a block.   You can have rural or municipal addresses etc.   Not all
address fields are needed for every address, and you do not want a single
null (undefined data) in the database.
So, in order to handle this, each address has a unique id, this is the
master link.   That master link is also linked to a definition of fields
that comprise this particular address.So, the first address is [street
number][street name] while the second is [plot number][rural road
number][municipality].So two addresses, in the same table, with totally
different columns.   You can add columns to the addresses on the fly, you
can even self populate the columns (surface them) based upon postal code.
Now, this is a full discussion on its own, but, it makes data very easy to
manage.
For example, lets say, you have 100 addresses, each address is in one city,
that city is in a state and that state is in a country.
Each one of those addresses would have a pointer to the city, which has a
pointer to the state, which has a pointer to the country.
So, you only ever have the country entered once in the database (with a
list of how it is used in various languages), same with state and city.
 This cuts the total size of the database enormously.

In order to handle a situation like this, you need a series of embedded
datapanels.

hmmm, I am thinking this may be very boring for the majority of people on
this list, perhaps there is a better list than 'using livecode' for this
discussion?



___
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: Panel/Form Widget

[Dalton Calford via use-livecode]

ok,

In order to explain what I need the utility for, is as a front end to a
highly normalized warehouse Temporal Graph database.
That probably means nothing to you, but, lets assume it does for the time
being.

For a simple example, lets say we are dealing with addresses, 2.6 billion
addresses, along with geo location.
The database does not contain nulls, data tuple width is variable based
upon a recursive multi-parent relationship.
Language/Locale information is part of the data structure
The client connects to a local embedded database which only is used for
work que's and caching and it in turn will connect to the middle tiers for
data synchronization/load balancing
Authentication is a round robin authkey token passed between the various
layers over an encrypted database to database channel.

(no, this is not star trek technobabble, it is actually a 1' summary of
a specification)

For discussions sake, lets agree upon some terms.

*Viewers* is not natural to me as I never heard the term used before this
discussion.   Lets use a different term

*DataPanel :- *This is the ultimate goal.


Ok, in order to explain what is going on, lets begin with a description of
a data warehouse problem.

A simple address.

An address has multiple elements, almost all of them defined identically -
a text string.   Depending upon your location on the planet, the details
are very different.   You could have street numbers or a building number
within a block.   You can have rural or municipal addresses etc.   Not all
address fields are needed for every address, and you do not want a single
null (undefined data) in the database.
So, in order to handle this, each address has a unique id, this is the
master link.   That master link is also linked to a definition of fields
that comprise this particular address.So, the first address is [street
number][street name] while the second is [plot number][rural road
number][municipality].So two addresses, in the same table, with totally
different columns.   You can add columns to the addresses on the fly, you
can even self populate the columns (surface them) based upon postal code.
Now, this is a full discussion on its own, but, it makes data very easy to
manage.
For example, lets say, you have 100 addresses, each address is in one city,
that city is in a state and that state is in a country.
Each one of those addresses would have a pointer to the city, which has a
pointer to the state, which has a pointer to the country.
So, you only ever have the country entered once in the database (with a
list of how it is used in various languages), same with state and city.
 This cuts the total size of the database enormously.

In order to handle a situation like this, you need a series of embedded
datapanels.

hmmm, I am thinking this may be very boring for the majority of people on
this list, perhaps there is a better list than 'using livecode' for this
discussion?



On Thu, 11 Apr 2019 at 14:58, Richard Gaskin via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Dalton Calford wrote:
>
> [lots of valuable stuff bookmarked but not quoted here only for brevity]
>
>  > But, if you are still with me, I am willing to explain what I use, how
>  > I use it, how it is used in many different applications and languages
>  > and why.
>  >
>  > I can provide specifications, tests and other aspects.   I am not
>  > asking for you to do the work, but, if you are willing to work with
>  > me, as I learn the in's and out's of livecode, I am sure we can come
>  > up with something.
>
> I like that collaborative spirit.  This helpful community is quite good
> that way.
>
> Maybe the simplest starting point would be a real-world example of
> immediate interest:  what are you building that needs Viewers?
>
> --
>   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
>
___
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: Panel/Form Widget

[Richard Gaskin via use-livecode]

Dalton Calford wrote:

[lots of valuable stuff bookmarked but not quoted here only for brevity]

> But, if you are still with me, I am willing to explain what I use, how
> I use it, how it is used in many different applications and languages
> and why.
>
> I can provide specifications, tests and other aspects.   I am not
> asking for you to do the work, but, if you are willing to work with
> me, as I learn the in's and out's of livecode, I am sure we can come
> up with something.

I like that collaborative spirit.  This helpful community is quite good 
that way.


Maybe the simplest starting point would be a real-world example of 
immediate interest:  what are you building that needs Viewers?


--
 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: Panel/Form Widget

[Dalton Calford via use-livecode]

Hi Richard,

I have no experience with such systems.  I only work with computers,
> where nothing happens until someone writes some code. :)
>

I understand where you are coming from, as I started out writing assembly
for 8088 processors and the whole idea of writing a loop in a high level
language is almost like not coding at all (c is just a macro'd version of
assembler was how we described it back in the day).

But from a "Livecode Users" standpoint, the idea of dropping a widget onto
a form, changing some properties and having it work as you want, is for all
intents and purposes, not coding.

;P

Anyways, onto the idea of a specification.

This is easy to do, but, it depends upon what you want the final product to
cover?

Also there is the issue of terminology.Livecode does not use standard
terms or concepts.
An example of this happens to be the concept of a Stack.

Live code Stacks would be defined in another language as follows

SDI Form
 --->Opaque Layered Panel
 --->Embedded Event Library
 --->Embedded Resource Library
 --->Embedded Style Library

Ok, lets start at describing what this means.
A window is named a form in most (not all) languages.
SDI means a single document format vs a Multiple document format
(discussion for another day)

On that form would be Opaque Layered Panel which in livecode terms is all
the layers of the stack.
Most languages do not use the idea of a stack and use a layered panel.
A panel is a container like a group, that has all the livecode properties
and a few more.  It behaves differently depending upon the IDE/RAD in use,
but most have similar interactions.

An embedded Event Library in other languages, is a series of code
snippets/functions/procedures that can be assigned to events.
For example, the hot key to pull up help, calls the same code that is
called when the help button or help menu item is called.
This is done by the various widgets having a list of events they respond to
(such as onclick, onmouseover, onmouseexit, ondoubleclick etc) and you
assign one of the event libraries code snippets to the widgets event.
 This uses quite a bit of referential code such as (self, parent, child
etc) but you can do the same with livecode.

An embedded resource library is similar to dropping a bunch of pdf's,
images, sound files etc all onto one stack and referring to them on another
page of the stack.With other languages, you general have an
object(widget) that you put the items into and it is a resource used by the
whole program.

An embedded Style library is like when you clone a control in livecode (but
a little more).   For example, a widget would have a property pointing to a
widget that holds all the default settings (such as geometry, colours etc)
and if you make a change to the style, it automatically has all the widgets
based upon that style update.   Again, this is covered in the background,
not needing any "Livecode User" coding.

This leaves out the ideas of source cursor (a pointer to a widget that
maintains/manages a cursor into an array or database table) as well as the
concept of the source filter (a property for master detail relationships)

Basically a database in many other languages have a series of widgets
[DatabaseEngine] (defines which libraries and settings are used when using
a connection)
[DatabaseConnection](defines the connection strings/user authentication
[DatabaseTransaction](defines transactional settings )
[DatabaseCursor] (Points to a sql query, table, view etc) Also has a
property for a source filter for master-detail

So a database aware widget (lets say a text edit) would have a pointer to a
field in the DatabaseCursor, which holds the result tuple from the current
row for the widget.
That DatabaseCursor would point to a transaction which in turn would point
to a connection, which in turn is connected to a database using the
DatabaseEngine properties.

Now, that is alot to digest.   Most people at this point go "TLDR" (too
long, didn't read) and we haven't gotten into the section covering single
panel or repeating panel containers...

But, if you are still with me, I am willing to explain what I use, how I
use it, how it is used in many different applications and languages and why.

I can provide specifications, tests and other aspects.   I am not asking
for you to do the work, but, if you are willing to work with me, as I learn
the in's and out's of livecode, I am sure we can come up with something.

best regards

Dalton




On Thu, 11 Apr 2019 at 13:05, Richard Gaskin via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Dalton Calford wrote:
>
>  > I am not saying groups are not workable, I am just saying, that in
>  > comparison to other 'container' style controls on multiple other
>  > development platforms, they are not as easy to use, nor as versatile.
>
> Can you tell us more about how they differ in regard to what you're
> currently building so we can use your real-world use-case to guide an
> implementation?

Re: Panel/Form Widget

[J. Landman Gay via use-livecode]

Hakan mentioned this but you may have missed it. You can definitely move 
controls around inside a group without breaking it apart or going into Edit 
Group mode. On the toolbar there's an icon called Select Grouped. Toggling 
that allows you to select the whole group (as you're doing now) or select 
only the control in the group you click on. I usually keep Select Grouped 
enabled all the time, I almost never have to go into edit group mode. And 
it's never required to ungroup just to make changes.


If you want to add a control to an existing group, copy (or cut) it, ensure 
Select Grouped isn't enabled, right click on the group and choose "Paste 
into group" from the contextual menu. Then re-enable Select Grouped and 
drag the control where you want it.


The group can be set to expand automatically if you move a control out of 
bounds, or to be locked so that controls are clipped when they move too 
far. Controls in the group will always keep their relative positions, so no 
scripting is required to manage that unless you want to change it dynamically.


Groups can have visible borders and they accept special effects so you can 
make them look like 3d floating panes.


Groups know their owner (and by extension, the owner of the owner) and 
their children, and LC can give you a list of all the group's children. You 
can have groups inside of groups.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On April 11, 2019 9:15:48 AM Dalton Calford via use-livecode 
 wrote:



Hi Hakan,

I am not saying groups are not workable, I am just saying, that in
comparison to other 'container' style controls on multiple other
development platforms, they are not as easy to use, nor as versatile.

In java, delphi, access, kde (the list goes on), you can do all the work
you are describing without a single line of code.
Drop a 'container widget' onto a form (stack), change the properties you
wish (transparency, mouse over, child flow, etc) and drop the widgets you
want onto it (changing their properties as needed).   The container
automatically becomes a type of object which you can inherit from and can
itself become embedded into another container.   No code needed.

In regards to having to align or group controls afterwards, in other
languages, you often will throw a series of containers onto a form, setting
up their alignment (including how any controls placed within them will
align to each other), then start putting the widgets such as buttons, text
fields etc after the layout has been completed.You can still move
widgets within each container without having to break the container (group)
apart in order to use your mouse to change a single widgets position in
regards to the rest.

Livecode has a great deal to say for itself, but, in this one area, it is
still in the stone age when it comes to modern practices.

best regards
Dalton Calford


On Thu, 11 Apr 2019 at 09:51,  wrote:


Maybe I don’t understand your idea but I do think you have kind of  the
same using a group. If you design your group or your ”panel” you still need
to place your controls. If you move a group you also move the controls
within that group. You can also grab individual controls in a group if you
click on the ”Select Grouped” button.
If you do want to place them programmatically you do have a relation as
all groups can know their children via ”of me”:


repeat with i = 1 to the number of controls of me
set the loc of control i of me to 
end repeat


Every control also know their parent via ”the owner”:
dispatch ”controlSelected” to the owner of me with the long id of me


Groups also get a message ”resizeControl” that I have used a lot when
creating my own ”controls” consisting of several controls in a group.


I can see the advantage if you are to build a fairly complex multi window
layout but still what to keep a one-window layout (ala Photoshop). But even
that should be doable with groups alone as if you drag a palette to be
free-floating you could create a new palette window and clone the group to
that window.


I usually drag out the controls and place them where I want them and then
select them and ”Group” them afterwards. If I want that exact group in
another project I can clone the group in one way or another.


So I can’t see the big difference...


But maybe [probably] I’m missing something…


:-Håkan
On 11 Apr 2019, 15:27 +0200, Dalton Calford via use-livecode <
use-livecode@lists.runrev.com>, wrote:


Hi Richard,
Thanks for your response!


So for the foreseeable future, we have groups, sharable within a stack,


and clonable anywhere, even into other stacks. Using that as a
foundation, we may be able to write a handler or two to give you a very
Viewer-like experience, if you can share more about the particulars of
how you'll be using them.




Although I can see the use of groups as an option, it is far less
intuitive and causes more issues than it should.
For example.
Calcu

Re: Documentation on Low Level Database Access

[Dalton Calford via use-livecode]

Hi Richard,
Thanks for the pointer.  I will look that up this weekend.
The database I am looking at is called firebird (www.firebirdsql.com).
It has embedded and standalone libs.  Supports windows, linux, osx and ios
along with android.
It is opensource and has native support for c++, c, pascal, .net, jdbc/odbc
etc.


On Thu, Apr 11, 2019, 1:09 PM Richard Gaskin via use-livecode, <
use-livecode@lists.runrev.com> wrote:

> Dalton Calford wrote:
>
>  > I am looking at the git repositories, the widget documentation etc.,
>  > looking for a solid guide on how livecode accesses database engines.
>  >
>  > For example, if I wanted to add low level support for another open
>  > source database that is available on all the same platforms as
>  > livecode, is there any documentation/standardization that I can
>  > follow?
>
> Does the DB engine provide a socket-driven API?
>
> If limited to C++, LC's source for rebDB is here:
> https://github.com/livecode/livecode/tree/develop/revdb
>
> If access is limited to C++, many options become available as we learn
> more about the specifics.
>
> What is its name?
>
> --
>   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
>
___
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: Documentation on Low Level Database Access

[Richard Gaskin via use-livecode]

Dalton Calford wrote:

> I am looking at the git repositories, the widget documentation etc.,
> looking for a solid guide on how livecode accesses database engines.
>
> For example, if I wanted to add low level support for another open
> source database that is available on all the same platforms as
> livecode, is there any documentation/standardization that I can
> follow?

Does the DB engine provide a socket-driven API?

If limited to C++, LC's source for rebDB is here:
https://github.com/livecode/livecode/tree/develop/revdb

If access is limited to C++, many options become available as we learn 
more about the specifics.


What is its name?

--
 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: Panel/Form Widget

[Richard Gaskin via use-livecode]

Dalton Calford wrote:

> I am not saying groups are not workable, I am just saying, that in
> comparison to other 'container' style controls on multiple other
> development platforms, they are not as easy to use, nor as versatile.

Can you tell us more about how they differ in regard to what you're 
currently building so we can use your real-world use-case to guide an 
implementation?



> In java, delphi, access, kde (the list goes on), you can do all the
> work you are describing without a single line of code.
> Drop a 'container widget' onto a form (stack), change the properties
> you wish (transparency, mouse over, child flow, etc) and drop the
> widgets you want onto it (changing their properties as needed).

So the workflow is quite similar to how we use LC's DataGrid.  Which is 
a custom control.  Which is what I proposed.  And which remains the most 
viable option for immediate results.



> The container automatically becomes a type of object which you can
> inherit from and can itself become embedded into another container.
> No code needed.

I have no experience with such systems.  I only work with computers, 
where nothing happens until someone writes some code. :)


Whether the core team writes it, or I write it, or you write it is the 
question at hand.


But if you want it, someone needs to write it.


> Livecode has a great deal to say for itself, but, in this one area, it
> is still in the stone age when it comes to modern practices.

Perceived modernity is fashion; my interest is in utility.

A request for this feature, known in the xTalk world as "Viewers" thanks 
to Gain Momentum having introduced it back in the mid-90s, has already 
been submitted:

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

Given the age of the request, as I wrote earlier I would not suspend 
development of current projects waiting for the core team to implement that.


If it must be done in the most expensive of options, in C++ within the 
engine, we can either continue to not have it while we wait for the 
engine team to build it, or spend considerable money hiring competent 
C++ professionals from the community to submit a series of pull requests 
for it.


But this is LiveCode.  There are nearly always multiple ways to solve 
anything.


The DataGrid would have been prohibitively expensive to attempt to 
implement in C++, which is why the flexibility it provides is nearly 
unnmatched among any other tool I've ever seen.


And so it can be with something very akin to Viewers.

We can build it.  Today.  We can have it.  We can enjoy it. Now.

But someone needs to write it.

And to do that, it needs a specification.

Which returns us to the question I asked earlier:  can you tell us more 
about the project you're building which requires this?



--
 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

Documentation on Low Level Database Access

[Dalton Calford via use-livecode]

Hi all,

I am looking at the git repositories, the widget documentation etc.,
looking for a solid guide on how livecode accesses database engines.

For example, if I wanted to add low level support for another open source
database that is available on all the same platforms as livecode, is there
any documentation/standardization that I can follow?

best regards

Dalton
___
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: Panel/Form Widget

[Dalton Calford via use-livecode]

Hi Hakan,

I am not saying groups are not workable, I am just saying, that in
comparison to other 'container' style controls on multiple other
development platforms, they are not as easy to use, nor as versatile.

In java, delphi, access, kde (the list goes on), you can do all the work
you are describing without a single line of code.
Drop a 'container widget' onto a form (stack), change the properties you
wish (transparency, mouse over, child flow, etc) and drop the widgets you
want onto it (changing their properties as needed).   The container
automatically becomes a type of object which you can inherit from and can
itself become embedded into another container.   No code needed.

In regards to having to align or group controls afterwards, in other
languages, you often will throw a series of containers onto a form, setting
up their alignment (including how any controls placed within them will
align to each other), then start putting the widgets such as buttons, text
fields etc after the layout has been completed.You can still move
widgets within each container without having to break the container (group)
apart in order to use your mouse to change a single widgets position in
regards to the rest.

Livecode has a great deal to say for itself, but, in this one area, it is
still in the stone age when it comes to modern practices.

best regards
Dalton Calford


On Thu, 11 Apr 2019 at 09:51,  wrote:

> Maybe I don’t understand your idea but I do think you have kind of  the
> same using a group. If you design your group or your ”panel” you still need
> to place your controls. If you move a group you also move the controls
> within that group. You can also grab individual controls in a group if you
> click on the ”Select Grouped” button.
> If you do want to place them programmatically you do have a relation as
> all groups can know their children via ”of me”:
>
> repeat with i = 1 to the number of controls of me
>set the loc of control i of me to 
> end repeat
>
> Every control also know their parent via ”the owner”:
> dispatch ”controlSelected” to the owner of me with the long id of me
>
> Groups also get a message ”resizeControl” that I have used a lot when
> creating my own ”controls” consisting of several controls in a group.
>
> I can see the advantage if you are to build a fairly complex multi window
> layout but still what to keep a one-window layout (ala Photoshop). But even
> that should be doable with groups alone as if you drag a palette to be
> free-floating you could create a new palette window and clone the group to
> that window.
>
> I usually drag out the controls and place them where I want them and then
> select them and ”Group” them afterwards. If I want that exact group in
> another project I can clone the group in one way or another.
>
> So I can’t see the big difference...
>
> But maybe [probably] I’m missing something…
>
> :-Håkan
> On 11 Apr 2019, 15:27 +0200, Dalton Calford via use-livecode <
> use-livecode@lists.runrev.com>, wrote:
>
> Hi Richard,
> Thanks for your response!
>
> So for the foreseeable future, we have groups, sharable within a stack,
>
> and clonable anywhere, even into other stacks. Using that as a
> foundation, we may be able to write a handler or two to give you a very
> Viewer-like experience, if you can share more about the particulars of
> how you'll be using them.
>
>
> Although I can see the use of groups as an option, it is far less
> intuitive and causes more issues than it should.
> For example.
> Calculating where to place/move an object within a group requires
> calculating where you want a new widget or where to move a widget in
> regards to the rest of the group, getting the top left corner of the group,
> combining the result etc., all in code.
> A parent/child with relative positioning is far simpler and closer to all
> modern systems.
> Another example,
> During development, in other apps, you drop a panel, drop your new widgets
> upon it as needed, and that is it.
> With Livecode, you either do not create the group until you are absolutely
> sure you know what you want in it, or, baring that, play with code or the
> project browser to move items into an existing group.
> Plus, using the pointer tool to move items within the group is also not
> possible as the items in the group are the items you use to click upon to
> move the whole group.
>
> This is a frustrating issue for what should be a simple thing. A
> 'container' would be the solution - effectively a smarter group, with
> widgets having a 'parent' and a possible array list of 'children'. This
> would allow a 'child' to know it's parent, and a 'parent' to know its
> children. Event notifications such as changes in geometry, style, etc
> could then be triggered/passed. It would also allow for simpler
> cropping/scroll bar mechanisms.
> It would also act as a scoping mechanism for variables and events.
>
> You could even have a stack as a child of another stack with this setup
> (MDI inte

Re: Saving a tab formatted field to a file and retaining its formatting

[Håkan Liljegren via use-livecode]

If you want the tab stops to be included in the file I guess you need to add 
them manually to the rtf file. There is a \tx command in rtf that sets the tab 
size. I used it long time ago so I don’t remember of it was relative or absolut 
positions but I do think it should be doable…

:-Håkan
On 8 Apr 2019, 18:25 +0200, Robert J. Earp via use-livecode 
, wrote:
> Thanks for the reply Paul. Yes, tried that but there are problems. It saves a 
> .rtf file but when you open that in MSWord (OS X or Windows) the tabs are 
> changed to underscores. If you open the file in OS X TextEdit it does have 
> tabs but the position/spacing is not retained. I’ve created a sample/test 
> stack if anybody wants to play ;-)
>
> Our project is supposed to create a formatted file that external to the LC 
> project, gets assembled with other documents/files to make a presentable 
> report. The other docs/files are .rtf (created in MSWord or Pages or 
> TextEdit) and an .eps file. The final report will be a .pdf and Acrobat is 
> likely what will get used to manually assemble the final report.
>
> To quote my valued colleague (RogerG) on this problem, and who has spent 
> inordinate hours trying to find a solution, tabs have turned out to be tricky 
> little devils in LC !!
>
> best, Bob...
>
> > From: Paul Dupuis mailto:p...@researchware.com>>
> > To: use-livecode@lists.runrev.com 
> > Subject: Re: Saving a tab formatted field to a file and retaining its
> > formatting
> > Message-ID:  > >
> > Content-Type: text/plain; charset=utf-8; format=flowed
> >
> > I take it your have tried:
> >
> > put the rtfText of field "X" into URL
> > ("file:"&specialFolderPath("desktop")&slash&"savedfield.rtf")
> >
> > And then reading it back to a new field with:
> >
> > set the rtfText of field "Y" to URL
> > ("file:"&specialFolderPath("desktop")&slash&"savedfield.rtf")
> >
> > and the tab spacing is not preserved?
> >
> >
> >
> > On 4/7/2019 7:57 PM, Robert J. Earp via use-livecode wrote:
> > > Dear all, we have a field that is formatted nicely with tabs and want to 
> > > save that as a file, retaining the tab formatting. The saved file format 
> > > ideally should be .rtf but we may be able to use other formats such as 
> > > .pdf
> > >
> > > Anybody got any ideas how to do this ?
> > >
> > > Thanks in advance for your suggestions.
> > >
> > > best, Bob?
> > >
> > > Bob Earp - White Rock, BC, Canada
> ___
> 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: Panel/Form Widget

[Håkan Liljegren via use-livecode]

Maybe I don’t understand your idea but I do think you have kind of  the same 
using a group. If you design your group or your ”panel” you still need to place 
your controls. If you move a group you also move the controls within that 
group. You can also grab individual controls in a group if you click on the 
”Select Grouped” button.
If you do want to place them programmatically you do have a relation as all 
groups can know their children via ”of me”:

repeat with i = 1 to the number of controls of me
   set the loc of control i of me to 
end repeat

Every control also know their parent via ”the owner”:
dispatch ”controlSelected” to the owner of me with the long id of me

Groups also get a message ”resizeControl” that I have used a lot when creating 
my own ”controls” consisting of several controls in a group.

I can see the advantage if you are to build a fairly complex multi window 
layout but still what to keep a one-window layout (ala Photoshop). But even 
that should be doable with groups alone as if you drag a palette to be 
free-floating you could create a new palette window and clone the group to that 
window.

I usually drag out the controls and place them where I want them and then 
select them and ”Group” them afterwards. If I want that exact group in another 
project I can clone the group in one way or another.

So I can’t see the big difference...

But maybe [probably] I’m missing something…

:-Håkan
On 11 Apr 2019, 15:27 +0200, Dalton Calford via use-livecode 
, wrote:
> Hi Richard,
> Thanks for your response!
>
> So for the foreseeable future, we have groups, sharable within a stack,
> > and clonable anywhere, even into other stacks. Using that as a
> > foundation, we may be able to write a handler or two to give you a very
> > Viewer-like experience, if you can share more about the particulars of
> > how you'll be using them.
> >
>
> Although I can see the use of groups as an option, it is far less
> intuitive and causes more issues than it should.
> For example.
> Calculating where to place/move an object within a group requires
> calculating where you want a new widget or where to move a widget in
> regards to the rest of the group, getting the top left corner of the group,
> combining the result etc., all in code.
> A parent/child with relative positioning is far simpler and closer to all
> modern systems.
> Another example,
> During development, in other apps, you drop a panel, drop your new widgets
> upon it as needed, and that is it.
> With Livecode, you either do not create the group until you are absolutely
> sure you know what you want in it, or, baring that, play with code or the
> project browser to move items into an existing group.
> Plus, using the pointer tool to move items within the group is also not
> possible as the items in the group are the items you use to click upon to
> move the whole group.
>
> This is a frustrating issue for what should be a simple thing. A
> 'container' would be the solution - effectively a smarter group, with
> widgets having a 'parent' and a possible array list of 'children'. This
> would allow a 'child' to know it's parent, and a 'parent' to know its
> children. Event notifications such as changes in geometry, style, etc
> could then be triggered/passed. It would also allow for simpler
> cropping/scroll bar mechanisms.
> It would also act as a scoping mechanism for variables and events.
>
> You could even have a stack as a child of another stack with this setup
> (MDI interface).
>
> If I had a better understanding of the codebase, I would implement it
> myself.
> But, If I had a better understanding of the code base, I would rather spend
> my time on the database layer which is woefully limited.
>
> best regards
> Dalton
>
> On Wed, 10 Apr 2019 at 18:11, Richard Gaskin via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
> > Dalton Calford wrote:
> >
> > > In other programming languages/environments that I have used, there is
> > > a normally a panel object.
> > > In livecode terms, it would act like a stack that is embedded inside
> > > another stack as a widget.
> > > With Delphi, it is a panel (tabbed; normal or repeating) while in
> > > MSAccess it is a form (repeating or not).
> > > My question is, does such a thing exist in livecode?
> >
> > LC has groups, which can contain any number of objects, and when nested
> > can even work like having multiple cards within them. They can be
> > shared across any card within a stack, but not across stacks*.
> >
> > Nice for some things, but if you want a true stack object within another
> > stack you may have to wait a while: this enhancement request is now 14
> > years old, for what Gain Momentum introduced to the xTalk world as
> > "Viewers"; while the LC team has shown interest in it, other priorities
> > have displaced its implementation:
> >
> > https://quality.livecode.com/show_bug.cgi?id=2786
> >
> > So for the foreseeable future, we have groups, sharable within a stack,
> > and clo

Re: Saving a tab formatted field to a file and retaining its formatting

[Eller, Roger via use-livecode]

Have you tried revPrintField? It's an oldie but goodie.



From: use-livecode  on behalf of Robert 
J. Earp via use-livecode 
Sent: Monday, April 8, 2019 12:24 PM
To: use-livecode@lists.runrev.com
Cc: Robert J. Earp
Subject: Re: Saving a tab formatted field to a file and retaining its formatting

Thanks for the reply Paul.  Yes, tried that but there are problems.  It saves a 
.rtf file but when you open that in MSWord (OS X or Windows) the tabs are 
changed to underscores.  If you open the file in OS X TextEdit it does have 
tabs but the position/spacing is not retained.  I’ve created a sample/test 
stack if anybody wants to play ;-)

Our project is supposed to create a formatted file that external to the LC 
project, gets assembled with other documents/files to make a presentable 
report.  The other docs/files are .rtf (created in MSWord or Pages or TextEdit) 
and an .eps file.  The final report will be a .pdf and Acrobat is likely what 
will get used to manually assemble the final report.

To quote my valued colleague (RogerG) on this problem, and who has spent 
inordinate hours trying to find a solution, tabs have turned out to be tricky 
little devils in LC !!

best, Bob...

> From: Paul Dupuis mailto:p...@researchware.com>>
> To: use-livecode@lists.runrev.com 
> Subject: Re: Saving a tab formatted field to a file and retaining its
>   formatting
> Message-ID:  >
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> I take it your have tried:
>
> put the rtfText of field "X" into URL
> ("file:"&specialFolderPath("desktop")&slash&"savedfield.rtf")
>
> And then reading it back to a new field with:
>
> set the rtfText of field "Y" to URL
> ("file:"&specialFolderPath("desktop")&slash&"savedfield.rtf")
>
> and the tab spacing is not preserved?
>
>
>
> On 4/7/2019 7:57 PM, Robert J. Earp via use-livecode wrote:
>> Dear all, we have a field that is formatted nicely with tabs and want to 
>> save that as a file, retaining the tab formatting.  The saved file format 
>> ideally should be .rtf but we may be able to use other formats such as .pdf
>>
>> Anybody got any ideas how to do this ?
>>
>> Thanks in advance for your suggestions.
>>
>> best, Bob?
>>
>> Bob Earp - White Rock, BC, Canada

___
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: Panel/Form Widget

[Dalton Calford via use-livecode]

Hi Richard,
Thanks for your response!

So for the foreseeable future, we have groups, sharable within a stack,
> and clonable anywhere, even into other stacks.  Using that as a
> foundation, we may be able to write a handler or two to give you a very
> Viewer-like experience, if you can share more about the particulars of
> how you'll be using them.
>

Although I can see the use of groups as an option,  it is far less
intuitive and causes more issues than it should.
For example.
Calculating where to place/move an object within a group requires
calculating where you want a new widget or where to move a widget in
regards to the rest of the group, getting the top left corner of the group,
combining the result etc., all in code.
A parent/child with relative positioning is far simpler and closer to all
modern systems.
Another example,
During development, in other apps, you drop a panel, drop your new widgets
upon it as needed, and that is it.
With Livecode, you either do not create the group until you are absolutely
sure you know what you want in it, or, baring that, play with code or the
project browser to move items into an existing group.
Plus, using the pointer tool to move items within the group is also not
possible as the items in the group are the items you use to click upon to
move the whole group.

This is a frustrating issue for what should be a simple thing.A
'container' would be the solution - effectively a smarter group, with
widgets having a 'parent' and a possible array list of 'children'.   This
would allow a 'child' to know it's parent, and a 'parent' to know its
children.   Event notifications such as changes in geometry, style, etc
could then be triggered/passed.   It would also allow for simpler
cropping/scroll bar mechanisms.
It would also act as a scoping mechanism for variables and events.

You could even have a stack as a child of another stack with this setup
(MDI interface).

If I had a better understanding of the codebase, I would implement it
myself.
But, If I had a better understanding of the code base, I would rather spend
my time on the database layer which is woefully limited.

best regards
Dalton

On Wed, 10 Apr 2019 at 18:11, Richard Gaskin via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Dalton Calford wrote:
>
>  > In other programming languages/environments that I have used, there is
>  > a normally a panel object.
>  > In livecode terms, it would act like a stack that is embedded inside
>  > another stack as a widget.
>  > With Delphi, it is a panel (tabbed; normal or repeating) while in
>  > MSAccess it is a form (repeating or not).
>  > My question is, does such a thing exist in livecode?
>
> LC has groups, which can contain any number of objects, and when nested
> can even work like having multiple cards within them.  They can be
> shared across any card within a stack, but not across stacks*.
>
> Nice for some things, but if you want a true stack object within another
> stack you may have to wait a while: this enhancement request is now 14
> years old, for what Gain Momentum introduced to the xTalk world as
> "Viewers"; while the LC team has shown interest in it, other priorities
> have displaced its implementation:
>
> https://quality.livecode.com/show_bug.cgi?id=2786
>
> So for the foreseeable future, we have groups, sharable within a stack,
> and clonable anywhere, even into other stacks.  Using that as a
> foundation, we may be able to write a handler or two to give you a very
> Viewer-like experience, if you can share more about the particulars of
> how you'll be using them.
>
>
>
> * Many years ago I experimented to find that you could display a group
> in another stack, but that was never intended and crashed hard as soon
> as you interacted with it.  Turns out showing groups across stacks was
> technically a bug, long since fixed. #HistoricalTrivia
>
> --
>   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
>
___
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: Panel/Form Widget

[Sannyasin Brahmanathaswami via use-livecode]

 Richard Gaskin wrote:

So for the foreseeable future, we have groups, sharable within a stack, 
and clonable anywhere, even into other stacks.

---

BR: 

Jacques taught this trick, I sure others do  it also, but FWIW

Though "globals are bad" . I do use one global in the app for "fixed assets" 
and not for holding runtime variables.

 1) In init was we have

global sConfigA

2) start using "lib_CustomControl" # a binary stack, one group control per card
3) After all dependencies run, this:

on init_StoreControlsIds
   put the long id of group "share-ui" of card "share-ui" of stack 
"lib_CustomControls" into sConfigA["shareControl"]
   put the long id of group "answerDlgGrp" of card "answerDlgGrp" of stack 
"lib_CustomControls" into sConfigA["answerDialog"]
   put the long id of group "bottomToast" of card "dialog_CustomMsg" of stack 
"lib_CustomControls" into sConfigA["bottomToast"]
   put the long id of group "searchControls" of card "search" of stack 
"lib_CustomControls" into sConfigA["search"]
   put the long id of group "sound-is-playing" of card "sound-is-playing" of 
stack "lib_CustomControls" into sConfigA["soundIsPlaying"]
end init_StoreControlsIds

4) in any other stack we can do this:

Mouseup 

case "share"
 put sConfigA["shareControl"] into tShareControl  
 if (exists(group "share-ui" of this card) ) then 
show group "share-ui" with visual dissolve very fast
 else  
copy tShareControl to this card 
 end if
break

running script profiler on this, the clone and show on a mouseup doesn't seem 
to have any more than a 2 milliseconds hit on the CPU. Virtually, this method 
has zero performance penalty. Of course the group is a "View" and cannot 
contain persistence date.

Advantage is obvious: If you need to make a change to a group, you do so one 
place, and it will appear "everywhere"


___
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: Upcoming MacOS 14.5 with software “notarization” requirements

[Richmond via use-livecode]

"There will always"

reminds me of that James Bond film, "Never Say Never Again" . . . better 
be careful

with pronouncements like that.

Richmond.

On 11.04.19 г. 11:12 ч., Andre Garzia via use-livecode wrote:
People forget that speed and latency are not related. Solving latency 
on networked apps is tricky.


There will always be a place for Desktop apps (local apps on your 
computer I mean)


On 10/04/2019 22:53, Richard Gaskin via use-livecode wrote:

Paul Dupuis wrote:

> Of course this may all be a mute point if you believe the "industry
> analysts" that say that 5G networks will kill the market for local
> applications whether for iOS, Android, or desktop OSes and finally web
> app will be fast enough :-)

All networks can get faster, but I'm with Steven J. Vaughan-Nichols 
in not holding my breath for 5G to be anything close to the magic 
pony marketers are playing it up to be:


"5G or faux G?: Forget all those stories of 20 Gbps speeds and 1 
millisecond latency. 5G will never deliver performance like that — 
and anyway its time is still years away for most of us most of the 
time."

https://www.computerworld.com/article/3336119/5g-or-faux-g.html


EFF has a similar view:

"Enough of the 5G Hype"
https://www.eff.org/deeplinks/2019/02/enough-5g-hype

...and an alternative infrastructure proposal that will benefit 
existing devices as well as the someday-soon-no-really 5G access points:


"The U.S. Desperately Needs a 'Fiber for All' Plan"
https://www.eff.org/deeplinks/2019/03/us-desperately-needs-fiber-all-plan 





With or without infrastructure improvements, I expect mobile to 
remain a steady growth segment.  But by "steady" I mean only slightly 
more than half of Internet traffic, with laptops being most of the 
remainder.


If Job's metaphor of the "post-PC" era means phones are cars and 
laptops are trucks, observe that the most popular auto form factor in 
the US is the SUV - effectively, a truck. :)


We're now a decade into the "post-PC" era, and Apple stills sells 
Macs. Lots of them.  More than iPads, which have leveled off to 
negative growth.


It's not just developers who need full computers.  It's everyone who 
isn't just a grazer: every artist, every writer, everyone making 
presentations. Nearly everyone.  You can do those things on a phone, 
just not as well.  With your thumbs.


For all the articles about the so-called "post-PC" era, I doubt any 
were typed with thumbs on a phone.


If only those writers could observe themselves as they work



___
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: Upcoming MacOS 14.5 with software “notarization” requirements

[Andre Garzia via use-livecode]

People forget that speed and latency are not related. Solving latency on 
networked apps is tricky.


There will always be a place for Desktop apps (local apps on your 
computer I mean)


On 10/04/2019 22:53, Richard Gaskin via use-livecode wrote:

Paul Dupuis wrote:

> Of course this may all be a mute point if you believe the "industry
> analysts" that say that 5G networks will kill the market for local
> applications whether for iOS, Android, or desktop OSes and finally web
> app will be fast enough :-)

All networks can get faster, but I'm with Steven J. Vaughan-Nichols in 
not holding my breath for 5G to be anything close to the magic pony 
marketers are playing it up to be:


"5G or faux G?: Forget all those stories of 20 Gbps speeds and 1 
millisecond latency. 5G will never deliver performance like that — and 
anyway its time is still years away for most of us most of the time."

https://www.computerworld.com/article/3336119/5g-or-faux-g.html


EFF has a similar view:

"Enough of the 5G Hype"
https://www.eff.org/deeplinks/2019/02/enough-5g-hype

...and an alternative infrastructure proposal that will benefit 
existing devices as well as the someday-soon-no-really 5G access points:


"The U.S. Desperately Needs a 'Fiber for All' Plan"
https://www.eff.org/deeplinks/2019/03/us-desperately-needs-fiber-all-plan



With or without infrastructure improvements, I expect mobile to remain 
a steady growth segment.  But by "steady" I mean only slightly more 
than half of Internet traffic, with laptops being most of the remainder.


If Job's metaphor of the "post-PC" era means phones are cars and 
laptops are trucks, observe that the most popular auto form factor in 
the US is the SUV - effectively, a truck. :)


We're now a decade into the "post-PC" era, and Apple stills sells 
Macs. Lots of them.  More than iPads, which have leveled off to 
negative growth.


It's not just developers who need full computers.  It's everyone who 
isn't just a grazer: every artist, every writer, everyone making 
presentations. Nearly everyone.  You can do those things on a phone, 
just not as well.  With your thumbs.


For all the articles about the so-called "post-PC" era, I doubt any 
were typed with thumbs on a phone.


If only those writers could observe themselves as they work



___
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