Resizing TableArrangement creates zombie components

I had a two column TableArrangement with 7 rows, 6 of them filled with components. After accidentally resizing the arrangement to 5 rows and subsequently extending it back to 6 rows the components from the original 6th row can’t be found anymore in the Viewer but still exist under Components.

Is there a way to revive them? If I’d simply delete them all code associated would be deleted too.

Table Arrangements are trouble. They are hard to arrange, hard to line up, and liable to copy/paste bugs.

Instead, squeeze in a Vertical Arrangement to your Screen, with Horizontal Arrangements for rows. Drag your components into the Horizontal Arrangements. You can set widths later at run time.

P.S. The Designer has Copy/Paste as Ctrl-C and Ctrl-V if you can't find the mock to drag.

1 Like

If you restore the old column/row counts the invisible components should reappear. Once you've done that, move them elsewhere in your screen and then you can decrease the column/row count back down to what you want.

1 Like

Thanks, that’s what I thought would happen but they don’t. The fields stay empty and the components orphaned.

Sorry, but I just wanted to remove an empty row and I think any resize operation should simply be aborted if it would result in orphaned components. It should not be possible to wreak havoc by (accidentally) reducing the size of a table arrangement (too much).

Thanks, I already tried that but I don’t get a vertical alingment unless I fiddle with the layout of each individuel row and that is destined to break on this device or another. I have a couple of I/O fields and corresponding labels. When I put them into a two column Table Arrangement everything is properly laid out, with vertical and horizontal alignment and without any tweaking.
The only problem is when components finally disappear from the Viewer when I (accidentally) reduce the size of the layout too much. And (Ok never open your sentences with a conjunction :wink:) … and from E. W. Pattons answer I conclude that it’s a bug.

BTW my tablet doesn’t have a control key. My Tinkerboard has but that doesn’t help me when I’m on my iPad.

Unfortunately I'm not able to replicate the behavior you've reported. I created a project with a 3x3 arrangement and placed buttons in the third row and column. I then reduced the number of rows and columns back to 2x2. I saved the project and reloaded it, and then on increasing the rows and columns back to 3x3 the buttons reappeared.

With your permission, we can access your account and inspect the project contents to see if there is some underlying reason for why this isn't working in your case.

Backup your project first. Then put all blocks (of the components, that you want to delete) in the Backpack. Delete the components and recreate them. After that get all needed blocks from the Backpack.

Yes but there is something to note. By accident I had the wrong project open when I started editing after creating a checkpoint. Thus my latest changes are in the Version 0.2.6 project and I already salvaged the problem there. Yet it is still visible in the main project (the one without a version number). In the Setup screen there you will find a “Label_Get_Current _Pos” and a “ListPicker1” which don’t appear in the viewer as well as an empty seventh row. I don’t need this main project any more. From the first CP labelled version on all important stages are in the checkpoints and I have local backups. So you are free to do anything you need on the main project, the one without a version number.

1 Like

Hello again. I think there is something more to discuss.

Though I had some issues I can’t understand the big problem you have with the Table Arrangements. From my testing I’d say adding a Horizontal Arrangement for each row isn’t any less troublesome but even worse as you can’t see the effect of your layout until you have your app running, can you?

Furthermore even though the ease of making dynamic changes is an advantage of the App Inventor (and I use it to hide some UI elements depending on context) the clear separation of design and code within the Viewer and Blocks editors is another one. That’s for the same reasons why the layout has been seperated from the data in HTML by introducing CSS.

When I start(ed) an AI project, I setup UI components and layout in the Viewer. Then I go to the Blocks editor, forget about the Layout and start coding. When that’s completed I connect with my devices through the Companion and start fixing. That’s a clean and simple workflow and I think what the AI layout suggests. The companion is awesome really but at times interferes badly with coding e.g. when error dialogs appear because of uncompleted changes. Thus I wouldn’t advise it when making bigger changes, i.e. namely in the third phase of the workflow I outlined.

@Anke: Yes, that can be a workaround but the backpack is barely usable on a tablet and I like using my iPad for small changes in between or starting a new project. I really find it intriguing to leave away the mouse and moving around the blocks with your finger. Yet it gets more difficult when the project grows.

Another option is to double check the numbers you enter in the rows and columns fields of a Table Arrangement but as it became obvious all that shouldn’t be necessary as the behavior I complained about is erroneous. That is the components should reappear in the Viewer once the Table Arrangement has been enlarged again.

@TIMAI2:

I had been alerted to that before my experience reading the Forum but

  1. I found out replacing the Table Arrangement with Vertical and Horizontal Arrangements isn’t really an improvement.
  2. The issue I reported is caused by an unintended behavior of the Viewer as it has become obvious in the discussion.
1 Like

Most, if not all, Power Users on the AI2 community will seek to steer you away from using a Table Arrangement, towards using vertical and horizontal arrangements instead. This is to help you avoid the sometimes buggy behaviour of the Table Arrangement in construction (designer) and use (companion/compiled).

If a Table Arrangement works for you, then fine, but now you have been alerted to (and experienced) the possible issues that a Table Arrangement can generate, which can be averted/negated/removed by using an alternative layout.

1 Like

Please note that you can't really know how any component, including the Table Arrangement, will look until you run your App in the Companion. You can replicate everything the Table Arrangement has to offer quickly and easily with rows of Horizontal Arrangements.

Concerning Components that can't be seen even though they are listed, they are recovered by logging out of App Inventor, then logging in again.

Now would be a good time to start using the Blocks Editor's individual Download Blocks as Image facilities for all you Event blocks and procedures.

There is an excellent Kevinkun browser extension to do a mass download in

I second that but to really know it you’d have to run the app on any device available and probably not only in the Companion, don’t you agree? In any case the Viewer shows the layout much more properly with a Table Arrangement than with the approach ABG suggested.

I did that several times especially overnight but the issue still is present in the project I mentioned to E. W. Patton.

To sum it up

  1. the issue I have reported apparently is a special case and should not occur
  2. in any case you should be very careful when making changes to an existing Table Arrangement
  3. yet I still think it is the best option for a set of pairs like some input fields and their adjacent labels. It needs a single layout component only independent of the number of rows and no runtime fixes.

Finally Anke proposed a viable solution for the question I posed. Thus I mark it as the solution.

3 Likes

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.