Page 1 of 2

Current IDE Oddities and Obstacles

Posted: Wed Mar 18, 2015 8:00 pm
by asayd
Hi Folks,

A few months back I solicited responses on the use-livecode mail list to the general question--What do new users (or even experienced users) find confusing about the LiveCode IDE? Now that the IDE has gone/is going open source on github, I thought I'd post the list here as food for thought:

LiveCode Interface Oddities and Obstacles

From Devin Asay:

Images and lockLoc

One of the most confusing things to new users is the requirement to lock size and location of images after you have resized them. If you don't they revert to their original size when you leave the card and return. Why not make this settable with a property?

Closely related: Why are lock size and lock location controlled by a single property?

General Misc.

Lack of reliable Undo

No auto-save to assist in recovery from crashes

Initial Startup State: What can I do, how do I start?

Stacks--closed but still in memory

By default closing a stack keeps the file open. This is one of the biggest sources of confusion and frustration for new users. It is too easy to save and close a stack window, then inadvertantly open an older version of a stack and then make the wrong choice on the confusing Save-Purge-Cancel dialog. Often the new user is convinced that all of their recent work has simply vanished, when in reality they just opened the wrong version of the stack. The default behavior should be that when a stack window is closed it is also removed from memory. I realize there are good and valid reasons for the current behavior, but it is confusing and offputting for new users. Experienced users can easily change the behavior.

Color selectors, graphics effects, gradient interface

Graphic Effects Filters: What are Gaussian, Box 1, 2, and 3?

Color selectors: When changing color settings you can bring up the color selector by clicking once on the color box. However, if you want to change colors for graphics effects you have to double click on the color box.

To create most control objects you drag an icon from the Tools palette, or double click a tool on the Tools palette. But creating a graphic object is modal--you select the graphic type, then click and drag to "draw" the graphic. Once you have finished creating the graphic you are still in create graphic mode and subsequent clicks will create a new graphic object. You have to choose the Edit tool to select your created graphic object.

Graphic object gradients: the From, To and Via gadgets are unusual, but not too hard to use and get used to. The problem is that because the edit gadget dots can be pulled outward to lengthen the connecting lines, it is easy to pull one of them out of the visual area of the card, making it difficult to edit later.

From Pete Haworth:
One thing that confused the heck out of me at the start is how the menu bar
changes depending on whether a stack or the script editor is in front (this
is on OSX).

When in the script editor, the menu bar shows File, Edit, Debug, Handler,
Window, Help and the File menu has no entries to open a stack, etc. When
on a stack, it shows File, Edit, Tools, Object Text, Development, View,
Window, Help.

So if I'm in the script editor and close all the open stacks, there is no
way to open another stack without opening either the application browser or
the Tools palette (and maybe other IDE stacks), neither of which I use.

I'm sure this is a result of Apple's HIG but I have to say things work much
better in this regard on Windows, where the script editor related menus are
in the script editor itself.

From Mark Wieder:
The contextual menu that pops up when you right-click on a control is
different from the one that pops up when you right-click a stack,
which is different from the one that pops up in the Application
Browser, which is different from the one that pops up in the Project

Drives. Me. Crazy.
Why are Edit Script and Property Inspector swapped?
Why can you Cut/Copy/Paste a control but not a card?
Why is copying a card so hard?

The Property Inspector changes size depending on what you're looking

Why do I have to bring up the Property Inspector at all (and then
change the context to Contents) in order to change the text of a label
(or other) field? Yes, I made a plugin (as have we all) that lets me
double-click a label field to edit the text, but why should I have to
do that?

I always get the Size and Position scale arrows wrong on the Property
Inspector. I keep expecting the uparrow to increase the value, no
matter how much experience I get fiddling with it.

From Mike Kerner:
Try resizing something, or using the alignment tools.

I just ran into this, again, this week, when I was trying to fix a vertical
line. The line is too short, so I changed the length. The line
lengthened, UPWARD. So I then changed the top of the line, thinking that
would help me except the bottom stayed and thus the line was shorter,
again, but I missed that the "resize" checkbox was unchecked - because, if
you don't have "resize" checked, then when you change a coordinate of an
object, it just moves the object.

What's even weirder about that is that normally, now, when I create a line,
if I resize it I get the even more bizarre behavior of having the line
lengthen in BOTH directions with the center fixed, which is generally
followed by my shaking my monitor and screaming at it.

Now, go try to use the equalize/align/distribute tools. Throw three or
four objects on a card and use them.

And another:
If you have your lappie hooked to two monitors at work, and you use both
monitors, and then you go home, guess what happens to windows, especially
on a Mac, where you are using multiple workspaces? That's right, the
windows, even the LC development windows, are off-screen somewhere at
3750,150, and your only hope of getting them back is to figure out what the
name of the development window is (say, the message box, or a properties
palette, or maybe the script editor" and then going to the message box and
moving it manually.

Devin Asay

Re: Current IDE Oddities and Obstacles

Posted: Tue Dec 22, 2015 12:16 am
by mwieder

Regarding "Stacks--closed but still in memory", I filed in June 2014. Still no traction other than being marked 'confirmed'.

Re: Current IDE Oddities and Obstacles

Posted: Tue Dec 22, 2015 6:01 pm
by jacque
Why are lock size and lock location controlled by a single property?
This may be something they'll just have to learn. The engine uses the most primitive structure, the object rect, which sets both of these (and more.) The same thing applies when getting the properties of an object, which doesn't return any of the derived properties that can be calculated from the object rectangle.

I suppose a feature request could be submitted to expand the language though.

Re: Current IDE Oddities and Obstacles

Posted: Tue Dec 22, 2015 6:38 pm
by FourthWorld
Useful list - thanks for posting it.

I've been thinking about this one:
asayd wrote:Why are lock size and lock location controlled by a single property?
How can one change the location of an object without changing its rect?

Re: Current IDE Oddities and Obstacles

Posted: Tue Dec 22, 2015 8:11 pm
by mwieder
You can change an object's location without changing it's *size*, though, and that's also controlled by the lockLoc(ation) property.
I'd like to see a lockSize property that wouldn't affect the location. I think that would be more intuitive than having to lock an object's location in order to fix its size.

Re: Current IDE Oddities and Obstacles

Posted: Thu Feb 11, 2016 7:43 pm
by ClintMA
Here's both an oddity and an obstacle to both new and experienced users:

Note from Dictionary entry for topLeft"
"Important! The order of the top and left parameters is reversed compared to the property name: left comes first, then top."

There are similar notes for topRight, bottomLeft, and bottomRight.

Likewise the order of items for the rectangle property is: left, top, right, bottom. But given the fact that the rect corners are related to topLeft, topRight, bottomLeft, and bottomRight, a more logical order for the rect would be: top, left, bottom, right.

Given the huge number of existing stacks that use the current definitions, how could this possibly be corrected?

One possibility would be that upon the release of a new version of LiveCode, the LiveCode engine would check each stack as it opens, and if the stack was created by an older version, use the old definitions, but if created in the new version, use the new, more logical definitions.

Re: Current IDE Oddities and Obstacles

Posted: Thu Feb 11, 2016 8:45 pm
by FourthWorld
I think the note about topLeft and bottomRight is simply information, not a proposed change in the behavior of the property.

The challenge here is both historical and linguistic: the original xTalk dialect, HyperTalk, defined those properties with their names and their orders to deliver an English-like quality while still maintaining compatibility with their definition of the rectangle order (t,l,b,r).

In English when referring to real-world objects we often say things like "top-right" or "bottom-left", and rarely say "left-bottom" etc.

So the name of the property is indeed potentially confusing to learners, with the only benefit that it's more akin to natural language.

Despite its potential for confusion, I doubt anyone has plans to change it for the reasons you noted. And what confusion there may be is minor and how it works easily learned.

Re: Current IDE Oddities and Obstacles

Posted: Fri Mar 03, 2017 5:00 am
by bogs
This was a fascinating read for me, new comer to x-Talk of any kind, but having experience in other languages.
Something I don't understand, and haven't been able to find any information on, is the label text alignment/font-size property. I hope I explain this well, if not, feel free to start throwing rocks ;)

In every other language I've programmed in, (certainly not an extensive list) text alignment for any control holding text is always left by default (fields, labels, but not buttons which usually are centered). Livecode labels are aligned right by default ? and apparently that default can't be set (or I just haven't found out how yet) through preferences or by setting the main stacks text options.

Since I am still in the learning stage, I am writing a number of 'snippet' or 'target' programs focusing on specific parts of the language or objects, and using LOTS of labels. Initially, I just set one labels text property and copied/pasted it for all the others. That still took a lot of time, so eventually I just created a stack with the property set, a 'default stack' if you will, and open that then save it as something else.

The problem with that approach appears two-fold,
1.) the 'closing the window doesn't remove it from memory' mentioned above (been bitten by that one more than once).
2.) forgetting to rename the default stack in multiple places overwrites my default template and really doesn't save any of the tedium of just going to the label property.

Ok, I'm windy, I apologize, but I would love to know if there is a way for ME to change this behavior and set the label to a default I can live with. Thank you for any help you can give me :)

P.s. Hi Jacque! Enjoyed the conferences immensely, looked like quite a handful to moderate ;)

Re: Current IDE Oddities and Obstacles

Posted: Fri Mar 03, 2017 8:06 pm
by jacque
The tools palette is a little deceiving. Under the hood there is really only one button object and one field object. All the difference "types" that appear in the tools are just the primary button or field with different properties set. This does make it easier to place pre-defined fields and buttons, but the default choices don't always meet everyone's needs. Like you, I also wish the default label was left-aligned most of the time.

In general I don't mess with it much, I just drag one to my stack, change the alignment and any other properites I need, and then duplicate it every time I want a new label. Your "default" stack is another way to do it, but I wouldn't actually develop from there, I'd just use it as a storage library to keep customized controls that I could copy and paste. But whatever works for you is the best way to do it.

Another way would be to write a short handler that just sets the alignment of a field under the mouse, or one that's selected with the edit tool. Drop it into the stack script, or a library script you put in use, and you'd only need to type the handler name into the message box to activate it. I have a whole library of little tweaks like that that I keep running in the background all the time.

Re: scripting conferences -- moderation wasn't hard, we have a very polite and enthusiastic community here and they are generally very well behaved. :) The hardest part was the organization before each presentation, but except for a couple of people who had to back out at the last minute, even that went well.

Re: Current IDE Oddities and Obstacles

Posted: Sat Mar 04, 2017 6:02 pm
by bogs
Thank you so much for the interesting ideas, Jacque ! I can't say at this stage that I've parsed them all correctly, but it certainly gives me something to look forward to :) The explanation on the tools palette in particular is enlightening.

Another oddity that I couldn't find an explanation for is something that apparently happens in the 'Name' property field on the inspector (doesn't appear to affect the application browser name of the object). My naming structure convention goes like this:
Label = lblName, Text field = txtName, Button = cmdName, etc.

I always use the shortest form of name that will make it self evident to me, for example [cmdAddRec] or [txtDate] (carry over from previous languages).

I've installed all the stable Lc IDEs from 6.1 to 8.1.3. In all of them, but more prevalent in the later editions, sometimes the name property will start to display erratically in the property inspector, txtDate might show up as txtDat| (<- cursor in the text box), and if you need to rename it, it presents an issue since you can't clear the name, or at least I haven't figured it out yet.

At first, I thought this might be Linux related (my default os), but I've also seen it happen in Windows. It doesn't seem to happen at the time I'm initially working on a project, but mostly after I come back to it. However, that may also be because I don't do many revisions on my initial start of a project. I haven't seen anything referring to possible naming issues, unless there is some kind of length limit on a single word name that I somehow missed ? I have seen longer and even multipart names used in examples I've come across.

A second oddity I think is related to my own limited understanding of the language so far. In every example of code I've seen so far, the name of the object referenced is in "", so I am pretty sure that is the accepted standard. However, I've also found that either of these two examples appear to work exactly the same:

Code: Select all

put it into field txtResult

Code: Select all

put it into field "txtResult"
What I would like to know is, are the quotes used because names might have spaces in them, like db queries are put into single quotes, or is the lack of quotes supposed to cause failures and just don't due to some quirk?

Thank you again for your help in getting me straightened out :)

Re: Current IDE Oddities and Obstacles

Posted: Sat Mar 04, 2017 9:03 pm
by jacque
I haven't ever seen a problem with object names like you describe, so I'm not sure what's going on there. I don't use the same conventions though, so you might try changing the prefixes to see if that matters.

All object names should be enclosed in double quotes. If they aren't, LC will do its best to see if there is an object with that name, but it introduces ambiguity and sometimes it will fail. If there are no quotes, the engine has to scan every control looking for a match, which is slower. But more importantly, if an object name is a reserved word you will get unexpected results.

Rule of thumb is to always quote literals and control names in scripts.

Re: Current IDE Oddities and Obstacles

Posted: Sat Mar 04, 2017 9:17 pm
by bogs
Thanks, I will make sure to make use of the double quotes then as the examples list.

Funny enough, the name property thing happened again today, and as the screen shows, its a property in the built in datagrid group, however this happens more with things I've actually renamed.
As shown, the name always shows up properly in the Project Browser, but the Property Inspector seems like a maybe will /won't. This was the 6.5 ide, but as I mentioned it also happens in the rest of the ones I use (all stable branch, not dp or testings). I don't have a mac to test on, but I do get it on linux, windows, and various virtual machines with variations of those os's (used for testing, but sometimes to fix up before deploying).

It isn't a show stopper, but certainly disconcerting sometimes.

*Edit - I did just find out that no matter how mangled it is in the property inspector, I *can* rename the item in the Project Browser (DOH!) :shock:
*Edit2 - I just found out that sometimes this happens in the project browser as well.

Re: Current IDE Oddities and Obstacles

Posted: Thu Apr 20, 2017 11:43 pm
by bogs
A couple of things I've seen that I can't explain, sometimes when you close the project your working on to switch to another project (close, remove from mem), you'll suddenly find all kinds of stacks I can only assume are part of the IDE in the project browser, like the printer stack, page stack, rev cursors stack (? ) . It happens in every IDE revision past 6.1,, more so in the 6.6.x + series (although I probably don't use 7 and higher enough to say that one for sure, it does seem like every time I do it happens).

I don't know if your supposed to be able to go back and forth within the revisions of the IDE, but if you open one of the later ones and get those strange substacks, they will then show up in the earlier versions.

Here is LC 6.5.2 (with the IDE panels set the way I left them, and the program as originally put together)
Program as originally laid out in 6.5.2
Here is LC 6.7.11 with a substack 'visualEffects' I never put there.
Program as opens in 6.7.11 with substack now added
Something else that is odd is that earlier vers. like 6.1-6.5 open the palettes and windows where I left them, later ones, they could show up in any arrangement, although the menu palette usually does go to the top of the screen at least.

I've also seen pretty generic code that worked flawlessly in the engine for say, 6.5, that had to be moved or didn't work as expected in a later revision. This could be due to a lack of understanding how it is supposed to work on my part, but here it is, you tell me.
The vers. I wrote this in was 6.5, in the main card (frmMain), where it works in LC 6.1, 6.5, and 6.52 -

Code: Select all

on openStack
   // clear all the fields in card "frmMain" to be ready for the time...
   go to card "frmMain"
   // testing code to clear all fields ...
    repeat with x = 1 to the number of controls of me
            if "txt" is among the characters of the name of control x then put "" into control x
    end repeat
end openStack
When I open it in 6.6.x or higher, however, it would no longer clear the text boxes ? I didn't see why, but I tried a few things, moving it to the main stack instead of the card, changing the wording from "among" to "contains", changing the 'me' keyword to the actual name (i.e. controls of card "frmMain"), etc. At some point I got it working in the later IDE, but don't understand why it didn't work as originally written?

Re: Current IDE Oddities and Obstacles

Posted: Fri Apr 21, 2017 10:42 am
by bn
Hi bogs,
on openStack
// clear all the fields in card "frmMain" to be ready for the time...
go to card "frmMain"
// testing code to clear all fields ...
repeat with x = 1 to the number of controls of me
if "txt" is among the characters of the name of control x then put "" into control x
end repeat
end openStack

I tried your code in LC 6.7.1 in LC 8.1 and LC 9.0 DP6 it does work exactly as you have posted.
I made a stack to replicate your setup.

I have no idea why it does not work for you. I assume you did not have suppress messages turned on in which case it would not work.

Kind regards

Re: Current IDE Oddities and Obstacles

Posted: Fri Apr 21, 2017 5:08 pm
by bogs
Thank you Bernd, least I know I am not crazy now (or at least not any crazier than before ;) ) for assuming it should have worked.

Other parts of the original code in the program worked during my testing it, and once the code was changed to where it was working again, it did actually work. Your assumption that suppressing messages was off is valid, when I start encountering wonky things it is the first thing I check (Yes, I've been bitten by that one a few times as well, learnings GREAT fun! :D )

As I said above, I can't explain it either, unless it is because I started this in 6.5 and copied it to the project folders of later versions after it was more or less complete (I separate my project folders for each vers. of LC). Why that would make a difference to LC I have no idea, it is a pretty generic bit of code. The reason for moving it up in LC versions was that I had found out (while looking for something else completely) that being able to scale programs was intro'd in 6.6.

Unfortunately, the 6.6.x group of LCs are pretty flaky on this system and tend to crash a lot, which made me assume it wasn't working for a different reason, so I moved it from there to 6.7.11, and then just for grins to 7.1.4 and 8.1.3.

I suppose it could also be that I have multiple vers. of LC installed at the same time ? Would that somehow affect other versions ? I usually use the 'all users' option during install, and this is a linux boxen. I suppose I could try moving the scripts around to VM's instead and see if the issues persist, I am pretty sure the palettes moving around doesn't happen in WINE, which I use through POL. POL separates each install and isolates it completely,but probably introduces its own quirks into the process as well as being a completely different environment than I encountered the problem on.

Sorry for rambling on, I'll hop out for a bit :oops: