LiveCode Forums.

Hi,

I'll look into that tomorrow.

Kind regards,

Mark

itay1023 wrote:The button doesn't return to it's first location (myLoc variable).

itay1023 hi,

Since you didn't send a sample stack, which is a very good thing to get better solutions by the way,
I'm guessing that you want that button return to the location of mouseDown moment, right?

If it's so, then you have to store that first location.
But I've noticed some other things.
For example, you put an if clause inside the mouseDown handler, but it doesn't serve a purpose.
You don't check that _startTheGame variable anywhere else and you put true into the lMouseClicked anyways.
It's either a mistake or I didn't understand your game's structure.

Try this change:
Hope it helps...

Best,

~ Ender Nafi

If I understand you correctly, the problem is not that the collision is wrong but that the control doesn't return to its original location. To solve this, you need to put the location into a local variable before moving and set the control's location to that variable when you finish.
Don't declare myLoc outside a handler. It messes up everything. Variables that start with "my" are for inside single handlers only.
I have noticed that in your theButtonVar handler, you're still using a visual effect, even though someone already told you that you shouldn't do this. Why don't you accept someone's advice and do as s/he says? You should do that before you ask for help again. The if statement with the exit mouseDown doesn't make any sense whatsoever.

Every time the mouseMove handler runs, which could be 20 times per second, you setthe loc of button "blueBubble" to -100,-100. This takes time but doesn't make any sense. Move that to the mouseDown handler.
Note that on tablets, you can't check if the mouse is up. Therefore, the comments related to checking if the mouse is up make no sense. That is also why we put false into the lMouseClicked variable in the mouseUp handler.
Btw theButtonVar is a really weird name for a handler. It is very weird to start a handler with "the" and even weirder to give a handler the name that you'd normally assign to a variable. Why do you do this?

I haven't included the theButtonVar# handlers here. Why do you finish each handler with the next handler? This makes your script less understandable and more verbose. Just write one long theButtonVar handler.

You shouldn't use the send command. The mouseMove message fires theButtonVar1, which in turn fires theButtonVar2 and all following handlers. Remove the send command. You also need to remove the cancel command, because if you don't use the send command, you don't need the cancel command anymore.

So, I hope that you understand that porting the script to iOS and Android takes a complete rewrite of the entire script. Therefore, you should start with my example and adjust that until you have something that does what you want. That will be much easier than adjusting your old script.

Kind regards,

Mark

Ender Nafi,

You forgot to declare the local variable lMouseClicked and there is no need to put empty into myLoc. Also, using the cancel command is unnecessary.

Kind regards,

Mark

Mark hi,

Actually, I didn't declare any of the script variables.
I've written that code snippet of mine as a patch to the script which Itay has sent in the previous post.
That's why I've put the cancel command, for example.
I have no idea what it does

Another thing is that the structure of Itay isn't effective in many ways.
Calling handlers in a chain from each other?

Games must contain an update screen routine;
to achieve a reasonable fps value and for many other benefits.

Game Academy has a sample for this.
Itay, I strongly advise it to you.


Best,

~ Ender Nafi

Thank you very much- all of you!!!
You helped me very much

Best,
Itay

Hi Ender Nafi,

Game Academi and LC University etc. are not for me. They are interesting to look at to see the learning approach, but I don't use them as a source for programming concepts and ideas.

I fully agree that the chain of handlers makes no sense. I wrote this in my previous message and I hope that Itay will rewrite his script.

Sometimes an updateScreen handler is useful, but sometimes games will be much faster if all objects have their own updating routine, independently from everything else in the game. I made a simple arcade game this way and it is surprisingly fast.

Kind regards,

Mark

Variables that start with "my" are for inside single handlers only.

Just a note for future forum readers to clarify: this is a developer preference, not a LiveCode requirement. LiveCode doesn't care what you name your variables or handlers, use whatever makes sense to you. It has become customary among some of us to follow certain guidelines in naming conventions, but except for restrictions on some forbidden characters, the LiveCode engine doesn't care.

And yet, Jacque, it seems to me that my suggestion is very useful for OP while in this particular case a relativisation of this advice doesn't seem appropriate.

Mark