Does triggering a button from within a function leave something on the stack?
User is playing a game against the computer. After user does something, (e.g. in button-pressed routine called User Plays), a button called Computer Play is enabled. When user presses it, the computer plays, and then enables user play. All routines essentially finish and wait for user input.
If, instead, I trigger the Computer Play button automatically from the bottom of the user plays routine, will I leave something on the stack? Will I be building up a huge series of nested functions and eventually run out of stack space?
swift button triggers stack
edited Nov 23 '18 at 10:55
Rengers
7,75512343
asked Nov 21 '18 at 12:52
Rob Smythe
1441114
add a comment |
User is playing a game against the computer. After user does something, (e.g. in button-pressed routine called User Plays), a button called Computer Play is enabled. When user presses it, the computer plays, and then enables user play. All routines essentially finish and wait for user input.
If, instead, I trigger the Computer Play button automatically from the bottom of the user plays routine, will I leave something on the stack? Will I be building up a huge series of nested functions and eventually run out of stack space?
swift button triggers stack
edited Nov 23 '18 at 10:55
Rengers
7,75512343
asked Nov 21 '18 at 12:52
Rob Smythe
1441114
1
Are you talking about a method calling another method that in turn calls the first method? As inokey mentions in his answer, that would be recursive, and you could cause infinite recursion and a STACK OVERFLOW in that case. You need to explain what you're doing in more detail.
– Duncan C
Nov 21 '18 at 14:22
An attempt to clarify. Suppose I'm coding checkers. There's a clickOnSquare routine. User clicks (on a legal square, etc) and the piece moves. Now it's computer's turn. User presses "Move" button and the computer does it. The clickOnSquare routine ended, and so did the movePressed routine. However, suppose just trigger the buttonPressed routine at the bottom of that clickOnEmptySquare routine. Now the computer makes its move automatically. Did that clickOnSquare routine actually end, or when user makes the next move (i.e. clicksOnSquare), was something left on the stack?
– Rob Smythe
Nov 29 '18 at 13:11
As I indicated in my answer, nothing about calling an IBAction method from code instead of triggering it in response to a user tap has any effect on memory. There's no "leaving stuff on the stack" as a result of calling the IBAction from other code. Period.
– Duncan C
Nov 29 '18 at 14:15
If you're talking about recursion then you need to be clear about that. Your comment "clarifying" your question doesn't really clarify much. You don't indicate which methods are IBAction methods triggered by button taps, or what methods are called by other code, or what the calling sequence is.
– Duncan C
Nov 29 '18 at 14:17
Edit your question to show your code that calls your different methods so we can see if you are calling it recursively.
– Duncan C
Nov 30 '18 at 3:38
add a comment |
User is playing a game against the computer. After user does something, (e.g. in button-pressed routine called User Plays), a button called Computer Play is enabled. When user presses it, the computer plays, and then enables user play. All routines essentially finish and wait for user input.
If, instead, I trigger the Computer Play button automatically from the bottom of the user plays routine, will I leave something on the stack? Will I be building up a huge series of nested functions and eventually run out of stack space?
swift button triggers stack
edited Nov 23 '18 at 10:55
Rengers
7,75512343
asked Nov 21 '18 at 12:52
Rob Smythe
1441114
User is playing a game against the computer. After user does something, (e.g. in button-pressed routine called User Plays), a button called Computer Play is enabled. When user presses it, the computer plays, and then enables user play. All routines essentially finish and wait for user input.
If, instead, I trigger the Computer Play button automatically from the bottom of the user plays routine, will I leave something on the stack? Will I be building up a huge series of nested functions and eventually run out of stack space?
swift button triggers stack
swift button triggers stack
edited Nov 23 '18 at 10:55
Rengers
7,75512343
asked Nov 21 '18 at 12:52
Rob Smythe
1441114
edited Nov 23 '18 at 10:55
Rengers
7,75512343
asked Nov 21 '18 at 12:52
Rob Smythe
1441114
edited Nov 23 '18 at 10:55
Rengers
7,75512343
edited Nov 23 '18 at 10:55
Rengers
7,75512343
edited Nov 23 '18 at 10:55
Rengers
7,75512343
7,75512343
asked Nov 21 '18 at 12:52
Rob Smythe
1441114
asked Nov 21 '18 at 12:52
Rob Smythe
1441114
asked Nov 21 '18 at 12:52
Rob Smythe
1441114
1441114
1
Are you talking about a method calling another method that in turn calls the first method? As inokey mentions in his answer, that would be recursive, and you could cause infinite recursion and a STACK OVERFLOW in that case. You need to explain what you're doing in more detail.
– Duncan C
Nov 21 '18 at 14:22
An attempt to clarify. Suppose I'm coding checkers. There's a clickOnSquare routine. User clicks (on a legal square, etc) and the piece moves. Now it's computer's turn. User presses "Move" button and the computer does it. The clickOnSquare routine ended, and so did the movePressed routine. However, suppose just trigger the buttonPressed routine at the bottom of that clickOnEmptySquare routine. Now the computer makes its move automatically. Did that clickOnSquare routine actually end, or when user makes the next move (i.e. clicksOnSquare), was something left on the stack?
– Rob Smythe
Nov 29 '18 at 13:11
As I indicated in my answer, nothing about calling an IBAction method from code instead of triggering it in response to a user tap has any effect on memory. There's no "leaving stuff on the stack" as a result of calling the IBAction from other code. Period.
– Duncan C
Nov 29 '18 at 14:15
If you're talking about recursion then you need to be clear about that. Your comment "clarifying" your question doesn't really clarify much. You don't indicate which methods are IBAction methods triggered by button taps, or what methods are called by other code, or what the calling sequence is.
– Duncan C
Nov 29 '18 at 14:17
Edit your question to show your code that calls your different methods so we can see if you are calling it recursively.
– Duncan C
Nov 30 '18 at 3:38
add a comment |
1
Are you talking about a method calling another method that in turn calls the first method? As inokey mentions in his answer, that would be recursive, and you could cause infinite recursion and a STACK OVERFLOW in that case. You need to explain what you're doing in more detail.
– Duncan C
Nov 21 '18 at 14:22
An attempt to clarify. Suppose I'm coding checkers. There's a clickOnSquare routine. User clicks (on a legal square, etc) and the piece moves. Now it's computer's turn. User presses "Move" button and the computer does it. The clickOnSquare routine ended, and so did the movePressed routine. However, suppose just trigger the buttonPressed routine at the bottom of that clickOnEmptySquare routine. Now the computer makes its move automatically. Did that clickOnSquare routine actually end, or when user makes the next move (i.e. clicksOnSquare), was something left on the stack?
– Rob Smythe
Nov 29 '18 at 13:11
As I indicated in my answer, nothing about calling an IBAction method from code instead of triggering it in response to a user tap has any effect on memory. There's no "leaving stuff on the stack" as a result of calling the IBAction from other code. Period.
– Duncan C
Nov 29 '18 at 14:15
If you're talking about recursion then you need to be clear about that. Your comment "clarifying" your question doesn't really clarify much. You don't indicate which methods are IBAction methods triggered by button taps, or what methods are called by other code, or what the calling sequence is.
– Duncan C
Nov 29 '18 at 14:17
Edit your question to show your code that calls your different methods so we can see if you are calling it recursively.
– Duncan C
Nov 30 '18 at 3:38
1
1
Are you talking about a method calling another method that in turn calls the first method? As inokey mentions in his answer, that would be recursive, and you could cause infinite recursion and a STACK OVERFLOW in that case. You need to explain what you're doing in more detail.
– Duncan C
Nov 21 '18 at 14:22
Are you talking about a method calling another method that in turn calls the first method? As inokey mentions in his answer, that would be recursive, and you could cause infinite recursion and a STACK OVERFLOW in that case. You need to explain what you're doing in more detail.
– Duncan C
Nov 21 '18 at 14:22
An attempt to clarify. Suppose I'm coding checkers. There's a clickOnSquare routine. User clicks (on a legal square, etc) and the piece moves. Now it's computer's turn. User presses "Move" button and the computer does it. The clickOnSquare routine ended, and so did the movePressed routine. However, suppose just trigger the buttonPressed routine at the bottom of that clickOnEmptySquare routine. Now the computer makes its move automatically. Did that clickOnSquare routine actually end, or when user makes the next move (i.e. clicksOnSquare), was something left on the stack?
– Rob Smythe
Nov 29 '18 at 13:11
An attempt to clarify. Suppose I'm coding checkers. There's a clickOnSquare routine. User clicks (on a legal square, etc) and the piece moves. Now it's computer's turn. User presses "Move" button and the computer does it. The clickOnSquare routine ended, and so did the movePressed routine. However, suppose just trigger the buttonPressed routine at the bottom of that clickOnEmptySquare routine. Now the computer makes its move automatically. Did that clickOnSquare routine actually end, or when user makes the next move (i.e. clicksOnSquare), was something left on the stack?
– Rob Smythe
Nov 29 '18 at 13:11
As I indicated in my answer, nothing about calling an IBAction method from code instead of triggering it in response to a user tap has any effect on memory. There's no "leaving stuff on the stack" as a result of calling the IBAction from other code. Period.
– Duncan C
Nov 29 '18 at 14:15
As I indicated in my answer, nothing about calling an IBAction method from code instead of triggering it in response to a user tap has any effect on memory. There's no "leaving stuff on the stack" as a result of calling the IBAction from other code. Period.
– Duncan C
Nov 29 '18 at 14:15
If you're talking about recursion then you need to be clear about that. Your comment "clarifying" your question doesn't really clarify much. You don't indicate which methods are IBAction methods triggered by button taps, or what methods are called by other code, or what the calling sequence is.
– Duncan C
Nov 29 '18 at 14:17
If you're talking about recursion then you need to be clear about that. Your comment "clarifying" your question doesn't really clarify much. You don't indicate which methods are IBAction methods triggered by button taps, or what methods are called by other code, or what the calling sequence is.
– Duncan C
Nov 29 '18 at 14:17
Edit your question to show your code that calls your different methods so we can see if you are calling it recursively.
– Duncan C
Nov 30 '18 at 3:38
Edit your question to show your code that calls your different methods so we can see if you are calling it recursively.
– Duncan C
Nov 30 '18 at 3:38
add a comment |
2 Answers
2
active
oldest
votes
No. Button IBAction methods are methods like any other. They get called, they execute their code, and they return. Their local variables get allocated on the stack, and then get popped off the stack when the function returns.
If you have memory leaks in your IBAction method they will occur whether the method is called from a button press or from another method.
If you don't have memory leaks, calling a button's IBAction method from another method won't cause a memory leak.
EDIT:
Note that if you have endlessly recursive code (where a method calls itself repeatedly, or method A calls method B which calls method A which calls method B and so on forever) then you can endlessly allocate more and more stack memory until you have a stack overflow and crash your program. However, you'll know about that pretty quickly. Your app will freeze for a few seconds and then crash, every time you go into endless recursion.
answered Nov 21 '18 at 13:59
Duncan C
92k13114196
See the edit to my answer to talk about recursion.
– Duncan C
Nov 30 '18 at 3:37
add a comment |
Every time you work with a recursion there's a slight chance something might go wrong. Your question could be answered differently based on how your code is executed on practice.
Do you use escaping callbacks or you just call your methods from within each other and so on. Please provide some code or at least pseudo version of it. The general answer for this will be - yes. You have a risk to run out of stack space if your recursion call is potentially infinite.
answered Nov 21 '18 at 13:59
inokey
1,080617
The OP did not mention recursion.
– Duncan C
Nov 21 '18 at 14:20
@DuncanC I've seen your answer and it got me thinking, I even thought of deleting my answer but I couldn't get to the decision. It feels like the call might be recursive (from the current description). I'll see if the OP updates answer or comments on that to decide if I'm wrong and have to delete my answer.
– inokey
Nov 21 '18 at 14:23
Re-reading the OPs question I see your point. He could be describing a recursive call, or not. It' isn't clear.
– Duncan C
Nov 21 '18 at 14:32
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53412467%2fdoes-triggering-a-button-from-within-a-function-leave-something-on-the-stack%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
No. Button IBAction methods are methods like any other. They get called, they execute their code, and they return. Their local variables get allocated on the stack, and then get popped off the stack when the function returns.
If you have memory leaks in your IBAction method they will occur whether the method is called from a button press or from another method.
If you don't have memory leaks, calling a button's IBAction method from another method won't cause a memory leak.
EDIT:
Note that if you have endlessly recursive code (where a method calls itself repeatedly, or method A calls method B which calls method A which calls method B and so on forever) then you can endlessly allocate more and more stack memory until you have a stack overflow and crash your program. However, you'll know about that pretty quickly. Your app will freeze for a few seconds and then crash, every time you go into endless recursion.
answered Nov 21 '18 at 13:59
Duncan C
92k13114196
See the edit to my answer to talk about recursion.
– Duncan C
Nov 30 '18 at 3:37
add a comment |
No. Button IBAction methods are methods like any other. They get called, they execute their code, and they return. Their local variables get allocated on the stack, and then get popped off the stack when the function returns.
If you have memory leaks in your IBAction method they will occur whether the method is called from a button press or from another method.
If you don't have memory leaks, calling a button's IBAction method from another method won't cause a memory leak.
EDIT:
Note that if you have endlessly recursive code (where a method calls itself repeatedly, or method A calls method B which calls method A which calls method B and so on forever) then you can endlessly allocate more and more stack memory until you have a stack overflow and crash your program. However, you'll know about that pretty quickly. Your app will freeze for a few seconds and then crash, every time you go into endless recursion.
answered Nov 21 '18 at 13:59
Duncan C
92k13114196
See the edit to my answer to talk about recursion.
– Duncan C
Nov 30 '18 at 3:37
add a comment |
No. Button IBAction methods are methods like any other. They get called, they execute their code, and they return. Their local variables get allocated on the stack, and then get popped off the stack when the function returns.
If you have memory leaks in your IBAction method they will occur whether the method is called from a button press or from another method.
If you don't have memory leaks, calling a button's IBAction method from another method won't cause a memory leak.
EDIT:
Note that if you have endlessly recursive code (where a method calls itself repeatedly, or method A calls method B which calls method A which calls method B and so on forever) then you can endlessly allocate more and more stack memory until you have a stack overflow and crash your program. However, you'll know about that pretty quickly. Your app will freeze for a few seconds and then crash, every time you go into endless recursion.
answered Nov 21 '18 at 13:59
Duncan C
92k13114196
No. Button IBAction methods are methods like any other. They get called, they execute their code, and they return. Their local variables get allocated on the stack, and then get popped off the stack when the function returns.
If you have memory leaks in your IBAction method they will occur whether the method is called from a button press or from another method.
If you don't have memory leaks, calling a button's IBAction method from another method won't cause a memory leak.
EDIT:
Note that if you have endlessly recursive code (where a method calls itself repeatedly, or method A calls method B which calls method A which calls method B and so on forever) then you can endlessly allocate more and more stack memory until you have a stack overflow and crash your program. However, you'll know about that pretty quickly. Your app will freeze for a few seconds and then crash, every time you go into endless recursion.
answered Nov 21 '18 at 13:59
Duncan C
92k13114196
edited Nov 30 '18 at 3:34
answered Nov 21 '18 at 13:59
Duncan C
92k13114196
answered Nov 21 '18 at 13:59
Duncan C
92k13114196
answered Nov 21 '18 at 13:59
Duncan C
92k13114196
92k13114196
See the edit to my answer to talk about recursion.
– Duncan C
Nov 30 '18 at 3:37
add a comment |
See the edit to my answer to talk about recursion.
– Duncan C
Nov 30 '18 at 3:37
See the edit to my answer to talk about recursion.
– Duncan C
Nov 30 '18 at 3:37
See the edit to my answer to talk about recursion.
– Duncan C
Nov 30 '18 at 3:37
add a comment |
Every time you work with a recursion there's a slight chance something might go wrong. Your question could be answered differently based on how your code is executed on practice.
Do you use escaping callbacks or you just call your methods from within each other and so on. Please provide some code or at least pseudo version of it. The general answer for this will be - yes. You have a risk to run out of stack space if your recursion call is potentially infinite.
answered Nov 21 '18 at 13:59
inokey
1,080617
The OP did not mention recursion.
– Duncan C
Nov 21 '18 at 14:20
@DuncanC I've seen your answer and it got me thinking, I even thought of deleting my answer but I couldn't get to the decision. It feels like the call might be recursive (from the current description). I'll see if the OP updates answer or comments on that to decide if I'm wrong and have to delete my answer.
– inokey
Nov 21 '18 at 14:23
Re-reading the OPs question I see your point. He could be describing a recursive call, or not. It' isn't clear.
– Duncan C
Nov 21 '18 at 14:32
add a comment |
Every time you work with a recursion there's a slight chance something might go wrong. Your question could be answered differently based on how your code is executed on practice.
Do you use escaping callbacks or you just call your methods from within each other and so on. Please provide some code or at least pseudo version of it. The general answer for this will be - yes. You have a risk to run out of stack space if your recursion call is potentially infinite.
answered Nov 21 '18 at 13:59
inokey
1,080617
The OP did not mention recursion.
– Duncan C
Nov 21 '18 at 14:20
@DuncanC I've seen your answer and it got me thinking, I even thought of deleting my answer but I couldn't get to the decision. It feels like the call might be recursive (from the current description). I'll see if the OP updates answer or comments on that to decide if I'm wrong and have to delete my answer.
– inokey
Nov 21 '18 at 14:23
Re-reading the OPs question I see your point. He could be describing a recursive call, or not. It' isn't clear.
– Duncan C
Nov 21 '18 at 14:32
add a comment |
Every time you work with a recursion there's a slight chance something might go wrong. Your question could be answered differently based on how your code is executed on practice.
Do you use escaping callbacks or you just call your methods from within each other and so on. Please provide some code or at least pseudo version of it. The general answer for this will be - yes. You have a risk to run out of stack space if your recursion call is potentially infinite.
answered Nov 21 '18 at 13:59
inokey
1,080617
Every time you work with a recursion there's a slight chance something might go wrong. Your question could be answered differently based on how your code is executed on practice.
Do you use escaping callbacks or you just call your methods from within each other and so on. Please provide some code or at least pseudo version of it. The general answer for this will be - yes. You have a risk to run out of stack space if your recursion call is potentially infinite.
answered Nov 21 '18 at 13:59
inokey
1,080617
answered Nov 21 '18 at 13:59
inokey
1,080617
answered Nov 21 '18 at 13:59
inokey
1,080617
answered Nov 21 '18 at 13:59
inokey
1,080617
1,080617
The OP did not mention recursion.
– Duncan C
Nov 21 '18 at 14:20
@DuncanC I've seen your answer and it got me thinking, I even thought of deleting my answer but I couldn't get to the decision. It feels like the call might be recursive (from the current description). I'll see if the OP updates answer or comments on that to decide if I'm wrong and have to delete my answer.
– inokey
Nov 21 '18 at 14:23
Re-reading the OPs question I see your point. He could be describing a recursive call, or not. It' isn't clear.
– Duncan C
Nov 21 '18 at 14:32
add a comment |
The OP did not mention recursion.
– Duncan C
Nov 21 '18 at 14:20
@DuncanC I've seen your answer and it got me thinking, I even thought of deleting my answer but I couldn't get to the decision. It feels like the call might be recursive (from the current description). I'll see if the OP updates answer or comments on that to decide if I'm wrong and have to delete my answer.
– inokey
Nov 21 '18 at 14:23
Re-reading the OPs question I see your point. He could be describing a recursive call, or not. It' isn't clear.
– Duncan C
Nov 21 '18 at 14:32
The OP did not mention recursion.
– Duncan C
Nov 21 '18 at 14:20
The OP did not mention recursion.
– Duncan C
Nov 21 '18 at 14:20
@DuncanC I've seen your answer and it got me thinking, I even thought of deleting my answer but I couldn't get to the decision. It feels like the call might be recursive (from the current description). I'll see if the OP updates answer or comments on that to decide if I'm wrong and have to delete my answer.
– inokey
Nov 21 '18 at 14:23
@DuncanC I've seen your answer and it got me thinking, I even thought of deleting my answer but I couldn't get to the decision. It feels like the call might be recursive (from the current description). I'll see if the OP updates answer or comments on that to decide if I'm wrong and have to delete my answer.
– inokey
Nov 21 '18 at 14:23
Re-reading the OPs question I see your point. He could be describing a recursive call, or not. It' isn't clear.
– Duncan C
Nov 21 '18 at 14:32
Re-reading the OPs question I see your point. He could be describing a recursive call, or not. It' isn't clear.
– Duncan C
Nov 21 '18 at 14:32
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53412467%2fdoes-triggering-a-button-from-within-a-function-leave-something-on-the-stack%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
Are you talking about a method calling another method that in turn calls the first method? As inokey mentions in his answer, that would be recursive, and you could cause infinite recursion and a STACK OVERFLOW in that case. You need to explain what you're doing in more detail.
– Duncan C
Nov 21 '18 at 14:22
An attempt to clarify. Suppose I'm coding checkers. There's a clickOnSquare routine. User clicks (on a legal square, etc) and the piece moves. Now it's computer's turn. User presses "Move" button and the computer does it. The clickOnSquare routine ended, and so did the movePressed routine. However, suppose just trigger the buttonPressed routine at the bottom of that clickOnEmptySquare routine. Now the computer makes its move automatically. Did that clickOnSquare routine actually end, or when user makes the next move (i.e. clicksOnSquare), was something left on the stack?
– Rob Smythe
Nov 29 '18 at 13:11
As I indicated in my answer, nothing about calling an IBAction method from code instead of triggering it in response to a user tap has any effect on memory. There's no "leaving stuff on the stack" as a result of calling the IBAction from other code. Period.
– Duncan C
Nov 29 '18 at 14:15
If you're talking about recursion then you need to be clear about that. Your comment "clarifying" your question doesn't really clarify much. You don't indicate which methods are IBAction methods triggered by button taps, or what methods are called by other code, or what the calling sequence is.
– Duncan C
Nov 29 '18 at 14:17
Edit your question to show your code that calls your different methods so we can see if you are calling it recursively.
– Duncan C
Nov 30 '18 at 3:38