LiveCode Forums.

Here's a few thoughts I popped down this morning.

feel that how to program in livecode is messy to, many time i don't really know where i put the code to do stuff

i try to put most thing in the stack, and then call them from object, but some times i forget that.

can just try to figure this program i did make, think it is pretty messy.

anyway, feel that it pretty good to make something fast, before you forget the idea.

if someone wonder, my code is a form of bayes calculator, using 3 slides and a big square.

can read about bayes here http://www.richardcarrier.info/bayescalculator.html

think its a never ending project for me

hpsh

I don't entirely see the link between your 2 postings here and my "squib" on modularisation.

The main point of my squib is a huge advantage of Livecode over many programming languages of the past
(and many that are still used) that I don't feel the Livecode people are "playing up" enough in their
publicity.

ok, then i probably misunderstand the pdf, english is not my first language :-/

look for me that it was about problems to find code in livecode source.

Hi
I'm going to pipe in here and agree with Richmond - and here's why.

MY favourite rapid application language (above Delphi/C++ Builder/ Clipper/Alpha 5 - and Pascal my alltime favorite language) for 25+ years was Visual Foxpro, the last version being Visual Foxpro last updated by Microsoft in 2004 but still working on windows 7 and probably 10.

Anyway when Visual Foxpro came in (originaly FoxPro for DOS then FoxPro for windows) we got an event model and what were then called "snippets".

Snippets are the "scripts" of each and every object/stack/card in Livecode - we had code in VFP that would list all the snippets together but there was never anything stopping us from calling a routine from our "button snippet" that was inside a .prg text file/library. We can do the same in Livecode by either creating a library stack or using the Stack Script as a library.

In VFP all the events (commands in LC parlance) for a form where encapsulated separately so we would never be able to see the snippet for the form load/activate/destroy/unload/show and the myriad more events we would pick from a pulldown.

I can tell you that the Livecode system - although all the events available we have to lookup/remember is much more flexible than the FoxPro and Delphi way of doing things.
The heirarchical way that code is passed up - especially being able to have "snippets" of code in groups encapsulating objects is really powerful.

Having used Delphi C++ Builder and VB - Delphi was great but having all the code in one humongous file was really a pain. Livecode allows me the ease of use of Foxpro with the power to have all the code I want to see in 1 place in 1 stack/card/group/library script if I choose.

Using behaviors we can have all the button scripts in 1 "behaviour button" on a "resources" stack if we want.

Messy Code
To answer your questions about messy code - you have only got about 7 "snippets" and I could find them all easily but your code is messy and difficult because you do not comment at all, you use short names which mean nothing at all "text1" , "text2" field "data", D1, D2 D3 D4 without explanation - see lack of comments, and lastly you split up code in 3 button and 3 scrollers where it would be easier in 1 place to easily tweak stuff.

You could make the 3 buttons call a procedure that has a switch statement with "cases" for the label of the target for instance. The same with the scroller code which looks pretty much the same but with different variables. You could put nearly all the code in the card/stack script or make all the buttons into a group "grpButtons" and put the code in there. Same for the scroller code.
To make it even easier the script in the buttons group could be just a mouseup only calling a routine in the stack script with the switch/case as above, that way you wouldn't even need to put a mouseup in any button just add the button to the group. - or as suggested above, just have one invisible behaviour button with the script - very flexible. "We don't need no Stinkin Class Inheritence"!!! - (although we can simulate them)

To some up it's not what you have - it's how you use it.


Regards Lagi

Here's a simple script to help you find your code.

It puts all the snippets into a temporary file and launches notepad to show all the scripts broken down by cards/objects/controls

It's a little brain dead as it works by putting the button with the code on the stack you are interested in but it works for me. If IOn hjad the time/inclination I would extend it and make it a plugin but ...

Lagi

about this messy code, my code was a private small project, i just used that as a example.

but the point for me is just that it to many places to put code, objects and so on, and many times in this problem, the problem was that someone mess up the name of a object, put the code wrong place, and so on.

so no, it not just me, and i have used other languages, like ruby, perl, c and some other.

Hi

My answer specifically told you, that have total flexibility to put the code wherever you want. In 25+ years of FoxPro I very rarely needed to print out a code listing although there where ways to do it. As Richard said the code is easier to understand in Context.

My suggestion of putting the button and scroller code in a group is a way to keep them all together but close to "the context:"

I wrote stuff in VB and Delphi and you had one or a few humongous files (if they were not broken up). In Livecode having short and to the point code within or near the container that uses it and a library stack or stacks is the way to go. I reiterate it's not what you have its how you use it.

You can put your code into cards,stacks,groups,objects, text files (code only stacks) and program like in VB,Foxpro or Delphi. With the others you have basically the equivalent of cards and text files - it's upto the programmer.

And I didn't call it messy code - you did. Even on small stuff (over 20 lines of code) i would still use meaningful variables.

Trust me I looked at Ruby,Python,Alpha 5, Servoy, Lianja, Harbour, Delphi, FreePascal, c♯ - everyone had a problem especially the lack of a coherent GUI drag and drop builder - Taking everything into account I can say quite categorically that Livecode is the Visual Foxpro of the future - and that's coming from someone who looked at Runrev/livecode over many years and couldn't get past the "baby" language of PUT A INTO B because i'm a "real programmer" and we don't need baby scripting languages - I lost 10 years of coding with my blatant stupidity.

The reason we have the a = b + 1 syntax in most languages is because when youthe original Fortran compiler with 5+ passes running with a core (external memory) of the equivalent of 18K ish bytes of memory every nibble helps.
As an interesting aside, the reason that the language FORTH is called FORTH and not FOURTH is that the IBM operating system it was running on limited filenames to 5 characters (to save space). Funnily enough although Foxpro does use the algorithmic way it can still use the old JPLDIS//Vulcan/Dbase code of nearly 40 years ago

STORE 100.00 TO lnTotal
STORE 100.00 TO lnTotal1, lnTotal2, lnTotal3

- Store instead of PUT , but I never used it except when I needed to initialize arrays.

Sorry I got carried away "I'm a believer"!!!

I don't know what all that had to do with messy code and code all over the place other than I think all things considered I have not regretted my decision to use Livecode as my main language, I just wished i'd made the move sooner. It I will not use it If I think another language would be easier/quicker for a specific project. I have PHP,Python,Freepascal,B4X/I/J, Swift and BBC Basic for windows (yes you read that right) in my quiver - so every problem doesn't look like a nail when you only have 1 tool - a hammer.

Lagi