Re: Panel/Form Widget
I do use google, but, the issue is return on time and investment. The entire purpose of the endeavor is as a front end to a database. Given the database layer has not been touched for years given that all the database bugs where consolidated back in version 2.16 and not touched until 2016 when the consolidated list was marked as 'not a bug' tells me that there is no intention to actually fix the limits to the system. So, why should I spend time, fiddling with the discussions of how to fix the panels (viewers) when a more fundamental issue happens to be the database layer itself. I am going to use html and javascript with an embedded local only web server, as that is less work than livecode. It's a shame. Livecode has so much potential, but, it is fighting itself. I remember when I first looked at livecode back in 2010, they where promising so much that still does not exist. On Fri, 12 Apr 2019 at 13:48, Stephen Barncard wrote: > Good lord, Dalton - you could use gmail which also provides all the other > Google free goodies including online photo services > If you are a programmer this should be the easiest part! > > sqb > -- > Stephen Barncard - Sebastopol Ca. USA - > mixstream.org > > > On Fri, Apr 12, 2019 at 10:01 AM Dalton Calford > wrote: > >> Yea, unfortunately, setting up a site that I can upload to, arrange the >> links etc., is more hassle than it is worth. >> The responses I got on my other thread (about documentation on adding >> another native database client) tells me that I am not able to continue >> with Livecode. >> ODBC is not going to cut it, there is no native jdbc control and the >> system does not seem to have any standardization in regards to database >> access(from a low level standpoint). >> >> I hope I am wrong, but I won't know until I dig further into the git >> sources. >> >> >> >> On Fri, 12 Apr 2019 at 12:45, Stephen Barncard >> wrote: >> >>> This is an old fashioned list, which allows no attachments. >>> Always use links. >>> >>> On Fri, Apr 12, 2019 at 09:40 Dalton Calford via use-livecode < >>> use-livecode@lists.runrev.com> wrote: >>> > Well, it appears this list is not the best place to use for such a discussion. I shared some notes and a screen shot and voila, I get this "Your message to use-livecode awaits moderator approval" > I don't know if Richard got the message or not, nor do I know if my post got approved, but with such a small size (32k) this is really tight if any diagrams/mockups are to be included. ___ 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 >>> -- >>> -- >>> Stephen Barncard - Sebastopol Ca. USA - >>> mixstream.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
Good lord, Dalton - you could use gmail which also provides all the other Google free goodies including online photo services If you are a programmer this should be the easiest part! sqb -- Stephen Barncard - Sebastopol Ca. USA - mixstream.org On Fri, Apr 12, 2019 at 10:01 AM Dalton Calford wrote: > Yea, unfortunately, setting up a site that I can upload to, arrange the > links etc., is more hassle than it is worth. > The responses I got on my other thread (about documentation on adding > another native database client) tells me that I am not able to continue > with Livecode. > ODBC is not going to cut it, there is no native jdbc control and the > system does not seem to have any standardization in regards to database > access(from a low level standpoint). > > I hope I am wrong, but I won't know until I dig further into the git > sources. > > > > On Fri, 12 Apr 2019 at 12:45, Stephen Barncard > wrote: > >> This is an old fashioned list, which allows no attachments. >> Always use links. >> >> On Fri, Apr 12, 2019 at 09:40 Dalton Calford via use-livecode < >> use-livecode@lists.runrev.com> wrote: >> >>> > Well, it appears this list is not the best place to use for such a >>> discussion. >>> I shared some notes and a screen shot and voila, I get this >>> >>> "Your message to use-livecode awaits moderator approval" >>> > >>> >>> I don't know if Richard got the message or not, nor do I know if my post >>> got approved, but with such a small size (32k) this is really tight if >>> any >>> diagrams/mockups are to be included. >>> ___ >>> 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 >>> >> -- >> -- >> Stephen Barncard - Sebastopol Ca. USA - >> mixstream.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
Yea, unfortunately, setting up a site that I can upload to, arrange the links etc., is more hassle than it is worth. The responses I got on my other thread (about documentation on adding another native database client) tells me that I am not able to continue with Livecode. ODBC is not going to cut it, there is no native jdbc control and the system does not seem to have any standardization in regards to database access(from a low level standpoint). I hope I am wrong, but I won't know until I dig further into the git sources. On Fri, 12 Apr 2019 at 12:45, Stephen Barncard wrote: > This is an old fashioned list, which allows no attachments. > Always use links. > > On Fri, Apr 12, 2019 at 09:40 Dalton Calford via use-livecode < > use-livecode@lists.runrev.com> wrote: > >> > Well, it appears this list is not the best place to use for such a >> discussion. >> I shared some notes and a screen shot and voila, I get this >> >> "Your message to use-livecode awaits moderator approval" >> > >> >> I don't know if Richard got the message or not, nor do I know if my post >> got approved, but with such a small size (32k) this is really tight if >> any >> diagrams/mockups are to be included. >> ___ >> 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 >> > -- > -- > Stephen Barncard - Sebastopol Ca. USA - > mixstream.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
This is an old fashioned list, which allows no attachments. Always use links. On Fri, Apr 12, 2019 at 09:40 Dalton Calford via use-livecode < use-livecode@lists.runrev.com> wrote: > > Well, it appears this list is not the best place to use for such a > discussion. > I shared some notes and a screen shot and voila, I get this > > "Your message to use-livecode awaits moderator approval" > > > > I don't know if Richard got the message or not, nor do I know if my post > got approved, but with such a small size (32k) this is really tight if any > diagrams/mockups are to be included. > ___ > 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 > -- -- Stephen Barncard - Sebastopol Ca. USA - mixstream.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
> Well, it appears this list is not the best place to use for such a discussion. I shared some notes and a screen shot and voila, I get this "Your message to use-livecode awaits moderator approval" > I don't know if Richard got the message or not, nor do I know if my post got approved, but with such a small size (32k) this is really tight if any diagrams/mockups are to be included. ___ 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
On Thu, Apr 11, 2019 at 12:05 PM Richard Gaskin via use-livecode < use-livecode@lists.runrev.com> wrote: > > 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. > After reading parts of this discussion I decided to upload some work I've done in this area to a Github repo and put together a basic README. I refer to the concept as Embeddable Views. Each embeddable view is a separate stack with a single card. An instance of an embeddable view is a group with `selectGroupedControls` set to false and `clipsToRect` set to true. When you edit and save the card then all instances of the embeddable view are updated. I've been using the code in a Levure helper as most of the logic revolves around making sure that every time you edit the embeddable view that all instances are updated. The Levure application structure makes this very easy to manage. Here is the url in case anyone is interested in checking out the code: https://github.com/trevordevore/levurehelper-embeddable_views I will also mention that the Baker's Assistant plugin provides a UI for previewing embeddable views and inserting them into a stack. https://github.com/trevordevore/bakers-assistant -- Trevor DeVore ScreenSteps www.screensteps.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 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: Panel/Form Widget
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
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
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
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
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
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.
Re: Panel/Form Widget
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
Re: Panel/Form Widget
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
Re: Panel/Form Widget
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
Re: Panel/Form Widget
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
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: Panel/Form Widget
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
Panel/Form Widget
Hi all, 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? 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
