I found this article:
which describes how to redistribute procedures after the fact, is there a setting in C11 just like there is in C5?
I’ve had a look through the settings but can’t spot it and the search function doesn’t seem too helpful. I can see a few XML files with config data, perhaps it’s buried in there somewhere?
Cheers,
Andrew.
Thanks Jane, I got that from the linked article.
In C5 when I create a new procedure it is in its own, new module. I’m set in my ways, I like it like that. It makes it somewhat easier when I’m searching for something, I know exactly what procedure it is in based on the first (or second) line of the .clw file.
C11 creates a new procedure in the module that happens to be selected (or the last one) and defaults to 10 procedures per module.
I want it set to 1. Each module containing 1 procedure only. Each new procedure in it’s own fresh .CLW file, not cohabiting the module of another procedure.
The process described is a manual process, C5 does it automagically.
Cheers,
Andrew.
Tools Menu
Application Options
Application Tab
Procedures Per Module
Edit add Rick’s point:
The Application Options menu item in the Tools menu is only available if you do NOT have any APP files open.
One key is the Application Options menu item in the Tools menu is only available if you do not have any APP files open.
Going forward I suggest you do this manually to keep related procedures together. E.g. Browse with Form, Reports and related child procedures. I use this to often switch to Module view and see many related procs.
This does have a slight performance improvement in the way memory is paged in/out because related procedures that are likely to be called (e.g. the Form) in the same module will be loaded with the Browse. The improvement is probably nothing significant, but why have random unrelated procedures grouped together and loaded. DAB discussed this at DevCon.
Examples of Browse, Form, Reports and related together:
I personally have 1 procedure per module. This helps with source control. I also have a naming convention, which @Rick_UpperPark recommends when using his tool for Application Source control.
ProcedureName_ApplicationName.clw
His tool, on first export app to source control - import app from source control will do the heavy lifting for you with regards to this.
Using this will mean you can’t redistribute procedure or repopulate modules any more, but as I’ve been using this method for a good while, I haven’t had need for it.
I have no idea if the applications are any slower using this method, as I don’t have a 486 to test with (Sorry @CarlBarnes, couldn’t resist).
Even if you are only using source control for a diff on your clw’s, this method works well.
Anyway, just my 2 cents worth.
Mark
I do know that the generation and compilation process is slower with 1 procedure per module.
All of my large systems are broken into multiple APPs so this really isn’t a concern of mine.
The granularity gained in the source control commits is worth it to me!
Ahh, that’s what I was looking for.
The menu item was disabled when I had an application open.
I agree. I follow the same aproach and helps me a lot.
Even with Clarion generating some code in different sequence each time… As an example, in the Window.Init procedure, some times the line
SELF.AddItem(Toolbar)
is generated before and other times after the lines
CLEAR(GlobalRequest) ! Clear GlobalRequest after storing locally
CLEAR(GlobalResponse)
Anyway… 
yes I use one procedure per module as well - it makes searching far easier for me.
I’ve not tried this but if you look in ABWINDOW.TPW for the two lines:
#PRIORITY(6000),DESCRIPTION(‘Setup Toolbar Object’)
and
#PRIORITY(6000),DESCRIPTION(‘Initialize the procedure’)
you will see they both have the same (clashing) priority of 6000.
try changing one to say 6010 instead of 6000 and see if it stops things jumping around.
I remember having a discussion about this more than a decade ago with Andrew Barnham who had done his own generator in Java and he had to do something like this to enforce unique priority numbers in the template chain so that the Clarion generated output consistently matched his. So if this solves your problem then kudos to Andrew.
Thank you all for the input. Lots to consider, but at least my main issue was addressed.
Cheers,
Andrew.
Good to know! I’ll try it soon…
Now it works as expected!
Thank you for the info!
great to know, thanks for testing!
I might have spoken too soon.
Yes, if nothing or the default CLW file is selected it will create the new procedure in a new module, but if a procedure is selected it will create a new procedure in the same module regardless of the IDE setting.
I’ve checked the setting several times, closed and opened the app, and the above is the behaviour.
Is your app tree in view-by-module mode when you add the procedure? If you are then the new proc goes into the selected module.
I was in module order.
When in alpha order or procedure order, they seem to be created in new modules.
Thanks Bruce.