That's not what I would recommend.
But before going into details about what else to do and why, how about trying something much milder, first, like this?
Code:
Do form2 && well, or however you call form2 and wait for it to return
Thisform.Refresh()
If that's not enough it's still far simpler to let form1 reinit itself after the call to form2 by doing
Code:
Do form2 && well, or however you call form2 and wait for it to return
Thisform.Init()
The question is, if that's sufficiently doing a refresh of the forms data as you think it should. If you create grid cursors in the form init code that could cause problems with grids that are already bound to these results, doing init also would not go through all initialisation of the form, the data environment of the form and the load does not run. Therefore you might rather need to redo form1 instead. But it's worth trying.
You know it's not recommended to call events. It would be cleaner to have a separate form method reinit and call that, put all code of init into it that should be repeated, i.e. when it's all code that's all code, and in the actual init also do This.reinit().
The reason you don't call an event is that this only calls the code in it, it does not trigger its base behavior, but in case you don't need the base behavior to happen, so what? Just notice this means if your init code determines whether a user even has the right to use the form and returns .f. to close the form by that, that's standard behavor of init events of all VFP classes, return .f. from an init and the object destroys. If you call this.init() and it returns .f. that would not close the form, as you're not retriggering the actual event behavior, you just call the code of the init. Such a scenario is unlikely to be a showstopper, as the user actually has successfully started the form already, but this validity and permission check might be necessary per record the form shows and then you undermine the machanism and give users a way to sneak into access of records not belonging to them by first viewing a record they are allowed to see, then start form2 to change the outset to see other records.
So even if you redesign the form to have a reinit() method the actual init event calls, you have to consider this change of behavior, too. What reinit returns will not have the same effect as what init returns as event. So you'd actually need to do RETURN This.reinit() in the init event, but in second runs the return value of reinit still does not cause the form to quit. That's what's important to understand. It's simple to avoid calling an event by adding user define methods, which don't have a native VFP behavior, but then you still don't get that behavior by calling the method instead of the event.
So if you really need and want to restart form1 after form2 finishes, then come back. It's not as trivial to let a form restart itself without getting in its own way because it still runs. I'd put the rerun into form.unload, which should do that based on some signal value telling it to do that rerun. Because you surely don't want every unload to cause a rerun, only in the case you returned from form2.
Chriss