Too Many Segdef (Compiler Error)

compiler
nettalk
Tags: #<Tag:0x00007f60c0ba15a8> #<Tag:0x00007f60c0ba1288>

#1

The “Too Many Segdef” compiler error has plagued my life for a few years now.

In the most layman of terms (because that’s how my brain works) it means: You have a procedure somewhere that has way too many lines of code, template or otherwise.

Specifically for me, it’s because I’ve been working with Nettalk and creating some very large forms.

So this post is related mostly to Nettalk (NetWebForms in particular). Am not sure how much it will hold with regular clarion (desktop) apps.

There are a couple of bits of wisdom I’ve gleaned (through others helpfulness!) that would be good to document so others can hopefully be helped.

PROCESS

1. If you get this error, go to your *.clw files and find the *.clw file causing the issue (sort by size is a good start). I keep all my clw files in their own folder, so it’s easier in that way, but whatever the case of your development environment, you need to find the clw. It’ll be one that’s pretty large.

2. Once you have the clw, you can work out the procedure that is causing the issue. Now when it happens, I’ve got a pretty good idea which one it was (it’ll be the form I just added something to, one of a couple of netwebforms that are sitting right at the edge of “too many segdef”).

3. Once you have the troublemaking form in your sights, you have a couple of choices.

CHOICE #1: Try and minimise the template code in the form.

With NetWebForms (Nettalk), there are a couple of things that can be done. You can, if you have a form where this won’t interfere, turn off all comments for the form. This will significantly reduce the amount of template code in the form. But you lose comments (full stop, no way around it except to hack Bruce’s beautiful template code).

You can also look at removing any redundant fields, perhaps merging fields whose functionality might be duplicated elsewhere in the form.

CHOICE #2: Rip the form to bits (with pen and paper first usually!) and rebuild it with multiple interfaces.

If you have a form that’s hitting the “too many segdef” error, then you have a big form.

You want to look at breaking it up regardless. Having lots of tabs/sections, scrolling for miles, none of that is ideal when you could swap out for half a dozen buttons that launch popup forms instead.

In my experience I’ve usually taken both of those options.

Here’s a screenshot of the once-too-many-segdef “Person” netwebform, now broken up into multiple interfaces with what I call “popup buttons” (urg).

Hope this helps.


#2

Thanks for this Stu.

I have this problem in my data dll, seems my dictionary is too big. I have switched the “Generate File Declarations in Modules” to on in the Global properties but that did not fix the problem. I already removed all possible obsolete/unused tables from the dictionary, cleared all the clw/inc/obj/map etc. and recompiled but still getting the segdef error.

Any ideas on how to fix this?

Thanks

Nardus


#3

Hey Nardus,

Did you sort the clws by size to find the “big” files, and then look at the procs in those modules?

If you’re getting this on a nettalk app, it can be because of a big form (although Bruce has done a lot of work on sorting this out).


#4

Hi Stu

It is the clw with the file declarations. Not a NetTalk application.

I do have NetTalk applications but this specific app is a Windows app.

Thanks

Nardus


#6

Right, the clw with file declarations.

If you use FM3, you might be able to do a large dictionary split (can’t remember what it’s called), that might help.


#7

If you are still seeing the declarations in the main module, then I’m not sure this switch is on. Do you perhaps have Multi-Proj in this app? That doesn’t support this switch.


#8

Hi Bruce

I am not using Multi-Project, I have switched that on and off recompiled every time, export to TXA, create new app from TXA, delete all source, obj, etc files and recompiled again but still getting the too many segdef error due to declarations in main module.

Thanks

Nardus


#9

Used the Very Large Dictionary Support in Capesoft’s FM3 and that solved the issue for me.

Thanks

Nardus