Intern objektkode-buffer på 64K?

Hvilken version af XAL sidder du med ?

Sorry. Det er jo også rigtigt. XAL kerne 3.5 og applikation 2.70.

Så kunne du overveje at skrive det kode, som du har inden for dine whiles om til funktioner (FNC-kolonnen i udviklingsmenuen) og kalde disse i stedet for at have koden inkluderet direkte i dine While.
Så vil du højst sandsynligt ikke støde på problemet mere.
Jo mere modulær koden er, jo bedre m.h.t. objektkodebuffer problemet.
Dog vil det betyde en lille smule performancemæssigt, men det er nok ikke noget du skal bekymre dig om.

Den er jeg ikke lige sikker på, at jeg forstår. Jeg går ud fra, at du mener, at den skal ind i MACRO-biblioteket (MAC-kolonnen), idet FNC ikke eksisterer?

Ahh ... sorry jeg så ikke lige det med applikation 2.70. Sorry.
Kerne 3.5 og appl 2.7 er vist ikke noget Microsoft ellers understøtter !!!

Men ok, hvis du har en kerne fra 3.5 kan du vel også skaffe dig en udviklingsmenu fra 3.5 (c_menu.dev).
Så kan du komme ind og lave funktioner !!!

Hvis du ikke vil gå den vej, er der ingen anden udvej end at lave koden i dine WHILE strukturer om til XAL-elementer, som du så kalder.
Det er en anelse mere besværligt, da det er lidt omstændeligt at transportere parametre til og fra en XAL-kørsel, hvis man ikke vil anvende denne hersens &PARM variabel.

Men stadig gælder at jo mere modulær koden er, jo færre problemer m.h.t. objektkodebufferens størrelse.

Koden er for så vidt fantastik modulær, så jeg vil lige prøve med XAL-kørsler, selvom det jo godt nok er noget besværligt. Jeg vender lige tilbage ...

Perfekt. Så virkede det. Det var en god ide. Tak for hjælpen!