For individual pricing, you could use TinyDB NameSpaces to keep prices in the phone, like in my Fruit Stand sample.
Alternatively, if you want a subscription model, you could set up individual sheets of prices named by user.
The internal class representation for Java and Android are mostly 16 bit, so the length of many things like methods tend to be 65535 bytes (2^16 - 1) in terms of individual instructions. One block might translate into many instructions at the App Inventor level. Some programming camps focus on things like computational complexity scores to indicate when methods become so complex to reason about that they should be broken down into smaller units. But as ABG has suggested, a lookup table (possibly loaded from a shared resource so you can update it independent of the app) would be a likely solution to the problem.
Here is a sneaky and lazy way to save and recover every text box you laboriously coded into your app...
Each text box has a Hint attribute, that you can set up unique and helpful, and hopefully suitable as a TinyDB tag.
There is an Every Textbox block that will return a list of every textbox component in the current Screen. Using Generic (any) textbox blocks you can loop through that list and
- test the hints and text values for 0
- load and save the text values from and to TinyDB using as tags the unique hints coded into the text boxes in the Designer
- set visibility depending on .Text value
- pair them with Labels whose text can be matched against the textbox Hint (give or take a trailing colon) for row-wide visibility control
You need lot of patience to build such a long table in the designer view. 
But this can be done by dynamic component extension like CompCreator.
The overly long procedure can be broken down into subprocedures called from the original procedure husk.
That should circumvent the procedure size limitation.
I like that idea for indexing the hints. However, really the essence is to only display items on the shopping list with non-zero quantity. This could be solved by simply outputting a sting into a text box. But then How do I edit the quantity of a long list without a floating text box? It does not appear possible to use a notifier to pop up a number-only input box. SO perhaps I could grab a sting and check for numbers only.
I need to do the input-output over probably. I thought I might use your idea and place a small icon beside each output line making the alt-text the index value. Then when clicked on I could unhide an input box to get the new price associated with the item clicked.
The real pain here is the lack of ability to dynamically generate textboxes or place images into the output text programmatically. Which means another long period of dropping images into the designer.
That could be very helpful. Especially binding a click to a label. Thankyou.
Regarding all those text boxes, consider the question of how many doggy doors do you need for a kennel?
Text boxes can be reused.
Here is a sample to study, where the same text box can be used to input many attribute values...
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.