Panel/Form Widget

[Dalton Calford]

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 at 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?
>
>
>  > 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
>   ____________________________________________________________________
>   Ambassador at FourthWorld.com                http://www.FourthWorld.com
>
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>