There are some good practices for simplifying block-heavy programs

I have a program with many blocks.

Basically it is an educational consultation :slight_smile:

There are some good practices for simplifying block-heavy programs.

It occurs to me, for example, to use blocks that serve many buttons that serve the same purpose.

But, can you make x blocks elsewhere and be called from the main program? Anyway, I say it but I have no idea if it is possible.

Thank you.

That sounds like a procedure.

1 Like

It sounds, it sounds :slight_smile:

Yes, but I have a lot of procedures, too. Rather, I was referring to Classes or libraries so as not to have all the blocks and procedures (for you) in sight, it is that both, so much block is almost impossible to read or work with.

You've hit the Blocks Editor wall.
So have I.
There is supposedly a Blocks Editor multi-tab feature in the works, but no forecast for when it would become available for testing.

I tried keeping current exports of my events and procedures in github for easier access.
You can FIND an event by dragging in its doppleganger from a PNG download file and following the red error arrows to the original.
That does not work for procedures. AI2 "helpfully" changes the procedure name when it detects the duplication. You can trace back to a procedure definition from a call to it, in the right click menu.

Sorry for my daring. I was in the old forum although little. Now I am new here. And I remember you fondly since you helped me in the past. (By the way, mine is not English, so I'm sorry again in case I put some nonsense.)

And I wanted to greet you as you deserve :slight_smile: well I send you my regards, young man.

Continuing with the topic, well, I will continue thinking about how to improve and simplify the reading of the blocks. Thank you.

Hi Andy,
just a visual trick : you can collapse the blocks and the procedures. I made a couple of apps with > 60 blocks (events, timers, procedures, variables, etc.).
By collapsing them you save screen. It's not a library nor a class, but the working space on the screen survives. And already tested procedures can be left in a corner.
At the end you can organize the screen areas where you put the procedures as they were different libraries.
Another thing that helps is to activate the grid. So you can store precisely on the screen the procedures.
Of course this applies to a single app. If you need to reuse pieces of code in various apps then you can use the backpack.

Quick and crude.... :smirk:
Here below an example: each procedure can be made by an hundredth blocks...once tested I forget it (more or less like a library) I know that I give inputs , and I obtain some services or outputs. You can write comments, to document each procedure, inside the procedure itself.

By the way, what you say is a very good idea and it is even very simple and fast to do.

Only those who believe it should be clear about one simple thing. Distinguish what is a screen or user view from what the compiler should do under the stage. He does not believe?

I'll give you an example: How many times do I see that a programmer does not know how to distinguish what is presented on the screen or in a printer from what is a form to store information. One thing has nothing to do with another. The screen presentations are mere readings and should be fast, but a form is something else, it is storage and writing to the database.

This of your tabs is the same, one thing is what the user sees and manipulates and another thing is what is handled behind (to summarize, everything is handled behind)

Thank you, you even made me cry :slight_smile:

No Andy, no cry ... (famous song of Bob Marley)... :sob: :sob: :sob:

Do not say that !!

With the nights that I have spent programming with the album of my friend Bob Marley :slight_smile:

:rofl: :rofl: :rofl: