Heap Overload and upper limits of large WINDOW in C5.5

I was asked to add some additional fields to a form but must have reached the outer limit for tabs and/or fields. It’s an old app (C55) and there are resources available to bring it up to a newer version of Clarion. Thought I’d ask if there is a work-around. The form is smallish in size but large on tabs (15). Have I reached the outer limits or is something else causing the heap overflow?

Thanks.

Jim

You could attach the Window source in zip. Not the procedure source, just the Window.

The new Designer previews any Window by generating a working program and compiling it. That would see if it works in 11.

C5.5 is 16-bit so would have less resources.

As a workaround you could add your new fields to another Window you open from a button.

Thanks Carl. I mistyped: NO resources to bring it forward. I’m happy to learn that about the new Designer, though. That might be a possibility.

I have just created a window with 20 tabs in C11 Window formatter


C55 is a blast from the past, but maybe you could be able to add additional tabs in the window source editor? I often use it to add tabs for windows that have many of them. Also please note you can put another SHEET control with some tabs on a tab.

          SHEET,AT(3,4,253,125),USE(?SHEET1),#ORDINAL(4)
            TAB('Tab1'),USE(?TAB1),#ORDINAL(5)
              SHEET,AT(11,47,243,72),USE(?SHEET2),#ORDINAL(6)
                TAB('Tab21'),USE(?TAB21),#ORDINAL(7)
                END
                TAB('Tab22'),USE(?TAB22),#ORDINAL(8)
                END
                TAB('Tab23'),USE(?TAB23),#ORDINAL(9)
                END
                TAB('Tab24'),USE(?TAB24),#ORDINAL(10)
                END
                TAB('Tab25'),USE(?TAB25),#ORDINAL(11)
                END
              END
            END
            TAB('Tab2'),USE(?TAB2),#ORDINAL(12)
            END
            TAB('Tab3'),USE(?TAB3),#ORDINAL(13)
            END
            TAB('Tab4'),USE(?TAB4),#ORDINAL(14)
            END
            TAB('Tab5'),USE(?TAB5),#ORDINAL(15)
            END
            TAB('Tab6'),USE(?TAB6),#ORDINAL(16)
            END
            TAB('Tab7'),USE(?TAB7),#ORDINAL(17)
            END
            TAB('Tab8'),USE(?TAB8),#ORDINAL(18)
            END
            TAB('Tab9'),USE(?TAB9),#ORDINAL(19)
            END
            TAB('Tab10'),USE(?TAB10),#ORDINAL(20)
            END
            TAB('Tab11'),USE(?TAB11),#ORDINAL(21)
            END
            TAB('Tab12'),USE(?TAB12),#ORDINAL(22)
            END
            TAB('Tab13'),USE(?TAB13),#ORDINAL(23)
            END
            TAB('Tab14'),USE(?TAB14),#ORDINAL(24)
            END
            TAB('Tab15'),USE(?TAB15),#ORDINAL(25)
            END
            TAB('Tab16'),USE(?TAB16),#ORDINAL(26)
            END
            TAB('Tab17'),USE(?TAB17),#ORDINAL(27)
            END
            TAB('Tab18'),USE(?TAB18),#ORDINAL(28)
            END
            TAB('Tab19'),USE(?TAB19),#ORDINAL(29)
            END
            TAB('Tab20'),USE(?TAB20),#ORDINAL(30)
            END
          END
        END

Anyway, I suggest you should upgrade. I had my app in C6.3 which is far better than 5.5 and I upgraded to C11 in 2021 as I was experiencing a lot of compatibility issues. New designer may be a challenge, to be frank I’m not so keen about these floating property boxes and the fact I cannot use keyboard shortcuts to navigate through them. Also please note that the feature to synchronize controls on your app with dictionary does not work anymore.

Thanks for the suggestion Greg. I’ll try creating things in the source editor.

Yeah, it’s a relic. But still humming along.

Are the USE variable names long? I recall years ago I worked with a window that had 100s of controls. I ended up having to go through and change all of the
?Prompt:PRE:MyField FEQs
to ?pmt1, etc.
After doing that I could edit the window again. This was back in C6.3.

1 Like

Yep, they’re pretty long. Thanks for the tip. I had to roll something out quickly, so I went with a window to handle the extra fields. I plan to revisit this when I get back to the project and see if that resolves it.

I appreciate the fast responses this has gotten – all excellent suggestions!

Exporting the procedure to TXA and then importing it into a new procedure can sometimes get rid of IDE crashes when the windows are heavily populated.

An IDE crash would occur less often or go away for me, when the IDE application setting Open dct files and Template files as Read-Only is unticked.

I normally have the Dct and template files set to read only, with the IDE shortcut opening the IDE in seperate memory space, in order to run multiple instances of the C6 IDE at the same time.

I found when I was getting crashes trying to access the window formatter of a heavily populated window, it was down to the App using a prior version of the templates, and it hadnt been loaded and compiled with the IDE application set to NOT read-only dct & templates.

TLDR, if the dct & templates is set to read-only, untick this option and recompile all the apps for your program.

Likewise I would also put the heavily populated window into its own app file, and link it in as DLL, in order to reduce corrupting the rest of the procedures in app file it came from.

Good idea to easily reduce code the designer must load into memory.

The wizard generates code like below (I took out the #ORDINAL() added in C7):

 PROMPT('&First Name:'),AT(7,20),USE(?STU:FirstName:Prompt),#LINK(?STU:FirstName), |
    #ORIG(?STU:FirstName:Prompt)
 ENTRY(@S20),AT(47,20,84,10),USE(STU:FirstName),#LINK(?STU:FirstName:Prompt), |
    #ORIG(STU:FirstName)
 PROMPT('&Last Name:'),AT(7,34),USE(?STU:LastName:Prompt),#LINK(?STU:LastName), |
    #ORIG(?STU:LastName:Prompt)
 ENTRY(@S20),AT(47,34,84,10),USE(STU:LastName),#LINK(?STU:LastName:Prompt),#ORIG(STU:LastName)
...
 BUTTON('OK'),AT(12,185,45,14),USE(?OK),DEFAULT,#ORIG(?OK),#SEQ(4),#ORDINAL(37)
 BUTTON('Cancel'),AT(61,185,45,14),USE(?Cancel),#ORIG(?Cancel),#SEQ(5),#ORDINAL(38)

With the consistent USE(?STU:FirstName:Prompt) it would be easy to search :Prompt) and replace with :Pmt) reducing memory a little (3 bytes per).

Much less memory if you do as Rick said and changed the entire ?STU:FirstName:Prompt to ?pmt#. I would write a little program to do that. You can just change them all to ?pmt without a unique number and the IDE will add a unique :# so its ?pmt:1, ?pmt:2 etc.

You can delete the #LINK(?xxx) attributes. AFAIK those are only used when deleting controls to delete related controls. That would save a lot. If you change all the PROMPT(?xxx:prompt) then the #LINK will be broken and not do anything.

You can delete most #ORIG(?xxx) as long as there is no #SEQ(#). SEQ indicates a Control or Extension template. Sometimes the template uses the #ORIG() to find its control so if you delete #ORIG you will lose that connection, that changes generated code.


@JimA using the Window… editor you can break your connection between Controls and Templates or Embeds, so take the below few steps to backup and check your work.

  1. BEFORE you start check the Embeds for Orphaned Embeds (last in the list). Either delete or move those.
  2. BEFORE make Backup your App. You can also export the procedure to TXA.
  3. BEFORE save the Original generated CLW to compare afterward.
  4. Each time you open the Window… Editor save the original code in another editor so you can refer to it if you accidentally delete something.
  5. After editing Window… check the Embeds tab for Orphaned Embeds. If you see any you messed up. You can try to fix it. Failing that cancel.
  6. After editing generate/build then compare the CLW to the one you saved. You should see no changes or you messed up.

For those doing this in C7 and after you have to be concerned with the #ORDINAL()'s. They connect controls to embeds. Don’t delete them. Remember they get renumbered each time you save the Window so you usually cannot paste them in from a saved copy.


My At Sort Tool will flatten the Window code making it easier to edit. For Windows be sure to select “Not Sorted”. It has a Clean button that will remove all the #LINK() and #ORIG(). As I noted above have backups and check your work.

You could modify it and add a button to replace all your PROMPT()s with a ?Pmp#.

Cool. Just looked at your tool. Thanks Carl!