Not sure whether your first code section is the actual code - and if so where it is located - or you meant to say that you programmed into the main forms Lostfocus event and into the mainforms GotFocus event.
Anyway, the DO FROM does the child form, I guess. That is what makes thaqt nbew child form get the focus and the main form lose the focus. There are further events going on, but one thing you should know for all time: You don't call events. Events are always caused by he events they are named after, so the form.LostFocus event happens, when any control of any other (VFP) form (of the same VFP process) gets focus. In short that means when you DO FORM (I assume you do that in a button or you may do it in the form init event) Then this new for4m gets the focus, or precisely said one control of that childform. Thus all controls of the main form lose focus which finally also means the form Lostfocus event runs.
If you run an event, you don't cause the event. So if you call form.lsotfocus or also for example call form.deactivate() that's not letting the form lose the focus or get deactivates, an event is not caused by calling the event method, the event method is executed because the event happens. If you call an event method, you just cause the code in this event to run, even though the event didn't yet happen.
And therefore that's wrong usage of events.
Next topic: RETURN.
While things work now, you get wrong why I recommended RETURN to you.
You initially said:
SitesMasstec said:
...but then, child form is active again, because it continues (please see '2'):
To prevent that I gave two alternative solutions, one was reaqrranging code into a DO CASE statement where each case is handled separately so you only get one messagebox and not both, the alternative solution I suggested was ending the method with a RETURN that would be put into the IF branch after.
I had and likely still have the wrong idea about what Thisform.Release() does, because the help say it releases and thereby ends a form. Well, it does, but it can only release the form, when all current code is done, so what is
not happening is that all code and the form is unloaded. The current block of code has to firswt finish, that's why you see the second message, too. What you said is telling you think the child form is activated again, no it is not, it just is still active.
So things like Thisform.Release() or also other commands like QUIT, for example, have no immediate effect. That's what's wrong in your assumptions.
The way you programmed it now does not need that RETURN, as that's now in the last line of code (the ENDIF isn't really code executing it's just syntax to and the IFD statement).
Well, a method, an event, a procedure or a function, even a PRG, all of which you can think of as the currently executing block of code on the callstack, all of these have one thing in common: They end only in 3 concrete ways:
1. There is no next line, the code ends, VFP will automatically do RETURN .T. in such a case
2. There is a RETURN progrmmed by you, that can also return .t. or any other value, but also a simple pure RETURN on its own works that way.
3. The CANCEL command. It's a bit more drastic than RETURN and may usually not be what you want to use, because it could end more.
Even though that last remark sounds it could help end the child form, no it's not what you'd use here.
Well, for completenesss sake an error happening can also cause an interruption, but that's not an exception I forgot, it's still possible the error handling code returns to the codeblock, which had the error, so even an exception like an error is not ending the current code.
That's what not only you don't have in mind.
RETURNs main usage is to retrun some value to a caller, it's the most significant line of a function returning its result to the caller.
Well, let's think about the caller. In your mind the caller of the childform is the mainfo. But that doesn't matter here at all. The "caller" of the click code is the button click event. So it's the OS provcessing an event. And the OS isn't receiving what you return. So the only reason to use RETURN from a click event of a button ius, that your code is structured in a way that you need to stop all further code from executing, so you RETURN. You don't return to the main form with that, not directly. You return to the idle state the application has before the mouse click triggered the button click code. That's what you return to.
And what happens next is that the current code block is done, no further events may be queued to also be executed next, so the release finally can cause its effect.
So in very short, if you don't understand and maybe don't even want to understand what I explained, when you want a call of THISFORM.RELEASE() to act immediately, end the current code block by also doing RETURN in the next line. Unless it's in the last line of code (except any ENDIF, ENDCASE, ENDDO, etc. syntax structure).
What activates the main form after the child form eventually releases is that the main form was the previously focused form, no more, no less. Not the RETURN.
And what you programmed into the main form GotFocus is okay, that could also be in the Activatge event, but does not matter that much.
All in all the click code in the main form can be reduced to just do the child form:
Code:
DO FORM CADASPOR && CADASPOR is the child form
The click code of the "save" button of the child form creating a new record could then just be:
Code:
IF EntradaValida="Sim"
SELECT PORTOS
GOTO TOP
SET ORDER TO SIGLAPOR && SIGLAPOR
SEEK thisform.txtSiglaPorto.Value
IF FOUND()
MESSAGEBOX("Sigla de Porto já cadastrado",0, "Erro")
ELSE
APPEND BLANK
REPLACE SIGLAPOR WITH thisform.txtSiglaPorto.Value
REPLACE NOMEPOR WITH thisform.txtNomePorto.Value
SET ORDER TO NOMEPOR && NOMEPOR
ENDIF
thisform.Release
&& no RETURN here, unless there's further code in the click you don't want to run anymore.
ENDIF
Last not least I made the error to offfer you two alternative solutions without pointing out one of them is enough, sory for that.
Applying both solutions wasn't getting you into trouble, but doing unnecessary things, besides some things that had nothing to do with my previous answer.
Chriss
