By appropriately calling a screen with 'open another screen' and passing it the necessary parameters, is it possible to make it execute some procedures and then return the results with 'open another screen', but without displaying a useless screen?
This to use common procedure by different screens.
Which procedure do you want to pass or execute?
Show some relevant idea or blocks?
It doesn't matter which procedure. The problem is that if I call a screen with 'open another screen' this displays an empty screen on my mobile phone which is of no use to me. I wish it was possible not to view it.
On that block usage there is 99.99% chances of the screen view, it cannot be invisible, but you can use that screen.
Why you want to invisible it? Run the procedure in the screen you are switching from to another screen.
If not able to run the procedure in the screen tell me, and tell me what you want to achieve with open another screen procedure, which you cannot be in the main screen.
Use virtual screens if you must, just do your "stuff" on the same screen, in the background, no need to use other real screens for this.
I now have 5 screens in the app. One of them contains procedures that must be used by two other screens. I don't want to have to repeat the same procedures in all 3 screens so I recall the screen that contains the procedures with the necessary parameters. Here it processes the parameters and returns the result to the calling screen. The screen containing the procedures has no objects on the screen. But this is displayed empty every time I recall the procedures as mentioned. I would like not to see the blank screen.
The alternative is, as TIMA12 suggests, to use virtual screen, but this only means transferring all the objects and blocks of the 3 screens into a single screen and burdening all the editing operations.
However, I understood that it is not possible to define an invisible screen in some way.
Show the progress notifier on the blank screens if you not like them a blanks and dismiss the progress on your work done.
And later on switch to the screen you wanted to after the procedures done in background.
You can also use AlphaDialog or DaffyDialog to make customer progress bars.
Thanks Harsh, I made my own progress bar that I use when needed. But most of the time the job requested to the procedure is done in 1 second.
.
Can these also be virtual screens ?
They could. But I would have a mess of blocks that have no relationship to each other in a single board. Managing several 'windows' of objects by placing them on different vertical arrangements is not the biggest problem, but it would be much cleaner if they were on different screens.
There is no problem in it, but it will definitely help to improve UI and skills also.
You also said:
The programming structure you created generated a problem that would be predictable... but you didn't know this when you created it...
Now that the problem has become evident and you are facing the consequences of your choice, you are trying to find ways to solve it... but the chosen programming language does not allow a screen to be invisible...
There are ways to solve the problem... but for this you will have to sacrifice 'something' of the original structure. Saying 'I Don't Want' and fighting with the chosen language will not solve the problem.
You will have to choose from the 'I Wish...', 'I Don't Want...', 'I Will Like...', 'I Willd Have...', 'I Don't Want To Have...' and opt for any of the solutions that solve the problem generated... Something that if you had been able to predict at the beginning, it would have been accepted in a good manner and would have generated the correct programming structure, according to the possibilities of language.
Try downloading the proposed *.aia in this post, by @uskiara... and see how this can solve your problem by bringing together the 5 screens created in a single one.
MultipleScreen.aia (849.0 KB)
You will probably have some work to transfer all the programming done on the other screens to the main one...
The issue of blocks layout, initially it can be resolved by grouping the blocks from each screen in different areas, in order to facilitate reasoning . This may seem confused at the beginning... but later then you get used to 'navigating' in the different areas of the editor.
Decidingly, this will solve your problem. While the processing you need is on a isolated screen, there is no way to prevent this screen from 'flash', even for a second... so it is necessary to know how to take a step back, so that it can fix the incongruities of a structure programming that already was born committed to a mistake. 
Lito
@>-->---
Thanks for the excellent explanation and suggestions. Now that I know these limitations exist I will act accordingly. I'm learning only with your occasional help and coming from other languages some limitations I've found here surprise me. I will study the .aia that you sent me and arrange mine as necessary. Thank you.
Great! 
Remember that to transfer your Blocks between Screens, you can use 'Add to Backpack' »
I believe this feature will be of great help in this case...
Lito
@>-->---