Graphic help needed

[ajperks]

I wanted to write a simple program that drew lines from specific points on a circle. (Mandelbrot)
However, I cannot find any tutorial on how to use the range of graphic commands.
I searched the dictionary. No help there.
I have taken apart various examples to see how the graphics were implemented. After bypassing bugs when initialising, tracking back through functions and mysterious code, there seems to be no consistency or clarity about how things need to be done.
So far, I have boiled the requirement for a line down to this.

Code: Select all

on mouseup
     create grc tLine
   
   set the style of grc tLine to "line"
   set the points of grc tline to 200,200, 300,300
   
end mouseup

Yes, I get a line, just where it should be, but I also get a flattened rectangle (like a basic text field) in the card centre that has no right being there.
The line and rectangle both have the name tLine in the properties.

Has anyone done a simple tutorial for the subject of graphic?

[Klaus]

Hm, just tested your code, copied into a button in a new stack, clicked it and ended with the line graphic ONLY!?
So it works for me on macOS 10.14.6 with LC 9.6.

[ajperks]

AJP mandelbrot.zip

(1.43 KiB) Downloaded 206 times

Try pressing the button twice. It draws the line on the first click and the rectangle on the subsequent one in this stack. I am using 9.6 on win 10
I hope that clarifies.
Thank you for looking.

[dunbarx]

Hi.

Confirmed here.

Subsequent clicks only produce rectangle graphics.



LC 9.6, on a Mac.

Craig

[ajperks]

Hi dunbarx,
So, I am not necessarily mad then.
All I wanted to do was plot a circle and a few lines.
1.5 days, and this is all I have to show for it.
Any advice?

[dunbarx]

Hi.

Not sure if you posted after my revisions.

There is no evidence you are not mad.

I am gong back to v8, and see what happens there. Watch this space.

Craig

[dunbarx]

Hi.

Same situation in V. 8.1.7.

Clearly a bug, but odd, since how does LC "know" that there is already a line graphic on the card, so that subsequent creations only make rectangles?

Do you know how to submit a bug report? Otherwise I will do it.

Craig

[ajperks]

Thanks Craig, I am sure a bug report will help someone, but not me. At nearly 75, I may not live long enough to enjoy the update or cure.
I have always enjoyed programming with RunRev or Livecode, but the re-learning curve is too steep if snags like this keep cropping up.
I do wonder if anyone uses the graphic because all the examples I looked at have code written in 2003 or thereabouts and all the apps were riddled with errors, most likely due to the current versions of livecode being so advanced. Nothing recent.
Thanks for your help.
Alan

[SparkOut]

I don't think it's a bug, unless I have misunderstood. It is because the second and subsequent graphics are created with the default graphic template properties.
But they have the same name as the first, so when you set the style of graphic tLine it finds the first graphic named tLine and sets the style (again).

[ajperks]

Why would that be a reasonable behaviour?
The computation is as new, each time the button is clicked. Why is there any carry over of anything to create a rectangle in a different location than the coordinates for the line.
Whilst not part of this thread, even the editor is dodgy because often I have explored an app and removed from memory without saving... only to find that it is still there and additional to the latest new load or piece of code.
I have used the Project browser to delete these rogue apps so I can see they are gone.
I don't need this hassle from what should be a matured system, by now. Experienced users may well be enduring these quirks and know the workarounds.
Thank you for your comment though.

[SparkOut]

Why wouldn't it be reasonable? You have created more than one graphic with the same name.
If you step through the code you see the process is create the graphic with the name "tLine" -you should really quote literal names, although it seems like you might want to name the graphic according to the value of the variable named tLine, which isn't specified so they all get named the same thing.
The graphic takes on the properties of the template graphic. You can set the template graphic to have properties that you want new graphics to inherit, before they are created if you wish. By default the type is a rectangle, and will be placed at the middle of the card.
Then after the graphic is created, you set its style and points to match the properties you want.
However, because you have all the graphics with the same name, all the engine can do with the instruction is to find the first one and set the properties. It's reasonable and mature behaviour to me. How would you propose this to be different, if you don't specify any more explicit identification?

[dunbarx]

I was actually ahead of Sparkout, who is perfectly correct:

Code: Select all

on mouseup
   put "tLine" & random(999) into tLine
     create grc tLine
   
   set the style of grc tLine to "line"
   set the points of grc tLine to 200,200, 300,300
   set the top of last grc to the top of last grc + random(100)
end mouseup

Click all day; nothing but lines now, and you can see them build.

So the issue is a subtle miscarriage of justice on LC, which was innocent all the while.

Craig

[SparkOut]

There are a variety of ways to address the graphic individually

Code: Select all

on mouseup
   create grc
   --the long id of the newly created graphic is return in "it"
   --they will have a unique id, but the same default name
   set the style of it to "line"
   set the points of it to 200,200, 300,300
end mouseup

Code: Select all

on mouseUp
   set the style of the templateGraphic to "line"
   set the points of the templateGraphic to 200,200, 300,300
   create grc
   --at some point you may want to reset the templateGraphic
   --otherwise ALL new graphics will be created with these same properties
end mouseUp

Code: Select all

on mouseUp
   break out the graphic creation into a handler that you pass a unique name
   createLineGrc ("tLine" & the number of graphics of this card + 1)
end mouseUp

on createLineGrc pName
   create grc pName
   set the style of grc pName to "line"
   set the points of grc pName to 200,200,300,300
end createLineGrc

[ajperks]

Thank you Craig and Sparkout for your assistance.
I wish I knew where you got your code information, I prefer to understand how things work rather than copy and paste.
I will press on with the suggestions you kindly made and see if I can move on with this experiment.
Regarding my own code, I remain unconvinced that it is not a bug in LC, but saying it isn't faulty when there seems no logical reason why a default rectangle should be added on the second click when it works as expected on the first click. As I see it, the code should run the same no matter how many clicks.

[dunbarx]

Hi.

We got our code information from our heads. The snippets are not "published" anywhere; both Sparkout and I made them up while sipping coffee, or hot chocolate in my case. I don't like coffee.

I digress.

But do you see the point of both our later posts? Not that I figured out the problem right away, like Sparkout did. I completely missed the naming issue.

When two controls have the same name, and you set a property referencing that name, only the control lowest in the layer order will respond. It is just how LC works, doing its best with, frankly, incomplete information. So you created a new graphic, which defaults to a rectangle, and then RE-SET the properties of the graphic that already was there. Of course, this made no difference to that one. The new graphic (and any subsequent ones) is ignored, remaining as a rectangle.

And so LC actually works just fine. Continue with your project. Graphics are stable and useful. I run a CAD simulator in a program we use every day, with many complex and dimensioned graphics that are created wholly from running code. One button click, and a drawing appears. An incredible time saver, and even though the final product is not as refined as what might be produced with AutoCad or SolidWorks, it is very close, and perfectly suitable for our clients.

Craig