I think it would be good if the template language had an %IniFile symbol which contained the full path to the IDE ini file being used.
I’ve got around it by writing my own DLL for #RunDll to return the path and filename, but it would make using GetIni and PutIni in a template expression a little easier imo.
Morning Richard,
Are you using C6 or C11?
I think your current solution is really probably the best one. There are two reasons for this;
a) you’re presumably wanting to read,or write, IDE settings? Thing is, those settings are in multiple files, and most of them are XML not INI. So I’m thinking that if you generically wanted to control IDE settings from the template language it’s likely not sufficient just to have an INI name. (Indeed scanning my current SV settings folder, they’re all XML, no INI).
b) C7+ allows for “multiple active clarion systems” (MACS). Meaning that you can have multiple “environments” running from a single IDE. (Although you still have multiple IDE’s as well.) Given that it uses different IDE settings folder per IDE (not environment) version, things could get very complicated quite quickly.
Add to this the availabiliy, and use, of /configdir and it very quickly gets out of hand.
Given the above a separate DLL to figure out what you want might be the best approach. Equally having it as a template prompt in the template (so the developer can be clear which one he wants to use) may also be an option.
Cheers
Bruce
Its for both, but still doing the development in C6 for now.
cool. In that context I don’t think C7+ even has “an INI file” for the IDE.
So I’m guessing your suggestion is largely moot on that front.
(I’m going to go out on a limb and suggest that the feature request window for C6 is closed 
)
Its that XML redirection file in C7+, but I havent delved into the the C7+ side of things recently.
As the template language doesnt give too much away ie PE or EE and what folder’s it running from I thought an %Inifile would be useful.
Space control of the layout of class file(s) from inside my class writing template.
Did you know there’s at least 4 different layouts for a class split over 1 or 2 files…
what do you mean by “layout” ?
The code in a class is fixed, it doesnt vary.
ProcName Procedure(Params)
[Data Definition]
code
[Program Code]
Its the Inc header & Clw class files that can change, namely the procedures that are defined outside of a class but included in the class files.
There’s two ways they can be called, so there is a drop down list option in my class writing template to define which ever way is preferred.
Two file (Inc/clw) class file.
Defined in the Inc class file.
Map
Module('ClassFile.clw')
Proc1(Params),Returnvalue,ProcedureCalling
Proc2(Params),Returnvalue,ProcedureCalling
End
End
or defined in the Clw class file
Map
Proc1(Params),Returnvalue,ProcedureCalling
Proc2(Params),Returnvalue,ProcedureCalling
End
One file (inc) class file.
Map
Module('')
Proc1(Params),Returnvalue,ProcedureCalling
Proc2(Params),Returnvalue,ProcedureCalling
End
End
or
Map
Proc1(Params),Returnvalue,ProcedureCalling
Proc2(Params),Returnvalue,ProcedureCalling
End
I’ll be glad when this is finished. 
Who would have thought writing a template to write Classes could be so involved?
Still I can use a Dct file to populate the class wide variables and 1 dct file to populate overloaded method variables with the option to use variable User Options to further restrict which overloaded class method the variable/property can be used in.
Dct Global to populate the appgen main procedure, with each non class proc having its own dct file for its own local variables.
If Dct use is preferred against the Data button in the procedure or writing it out by embed hand code.
It even populates ToDo class methods with a default message to inform its not completed.
So far 151 procedures…
Built using my 2nd work in process Template Builder.
Actually I wrote an extension template for the SourceClass template that allows me to define methods etc and write them to the appropriate places. It isn’t that big either.
Its been changing as I use it.
Eventually I want this template to import class source files so it needs to accommodate the different ways a class can be written out.
Plus I wanted it to work so that someone with no experience of writing a class wouldnt get bogged down reading various help doc pages to get the info because its spread over 3 or 4 pages.
Tooltips in the templates explain the controls and the defaults are set so someone could dive straight in and write the code for their class with just rudimentary AppGen clarion code experience, all the class syntax is handled automatically. You cant really make a mistake writing a class and in a way its probably the most efficient way to get up to speed with writing a class.
So I would be hard pushed to shrink this to an extension template, but I do have an extension template which add’s in OutputDebugString code to the methods and procedures to see the class running in DebugView.
Its also the first run of my Template Builder, so thats been changing as I use it in anger.
Which source class template are you refering to? I have EE from 6-11, and thats something I’m not aware of. Could be good to have a look at.
Edit. Oh and this is a new template chain in its own right as well.
As someone who has written something like a 1000 clarion classes. IMO The main problem with writing classes inside of an APP is you’re stuck in a modal environment.
Sure, you can use the embeditor to work with multiple embed points at once, but there’s only one editor window, so you’ll spend a lot more time scrolling around. Furthermore you cannot simultaneously view the INC and CLW.
On top of all of that you’re stuck in the SV.IDE editor, which I would describe as painful at best. (search backwards anyone?) IMO It’s only value is in supporting window and report formatters.
Its not going to please everyone, especially those who like to hand code 
, and thats a big/primary divide in the programming world but one of the attractions of Clarion is the Dct and AppGen.
I work best inside the AppGen.
I can have a clarion Dct instance open on one monitor, with one or more instances of the clarion AppGen open on other monitors.
What it brings to the table, is no longer having to define variables and groups by hand, thats handled by the Dct editor or Procedure Data button. So no syntax errors there.
When in the embeds, you have the dct file/field window to double click on and add a variable/property to the embed code like I do with a normal clarion app.
I dont have to worry about text alignment, thats taken care of automatically, so you can have perfectly formed classes every time.
I found the AppGen tree contraction/expansion better than code folding in an editor, with the added benefit, I can select a different tab and change the sort order from Tree view to name view and back again.
Sure there’s a bit more drilling down inside a procedure compared to a text editor, but thats how I like to work.
If developing one or more classes with the Class Writer, it handles the Class Module() & Link() settings automatically and still has the ability to add additional Include() files, for separate source files, like an Equate.clw file or parent class file.
It handles the parameter’s properly, so you cant define an parameter with the wrong syntax.
The template prompts also remind the programmer what can and cant be done in each section as well.
The Class Writer template wont let you make a syntax error, its defaults are setup for a default ABC class library, but all options can be adjusted easily within the template.
Since OOP was introduced in C5/C5.5 I’ve waited all these years for something like this, and there’s been attempts by others, but I’ve always found them to be a bit too clunky. So I ended up writing a template which works the way I think one should inside the AppGen.
The other benefit is, what I have here can now be adapted for other programming languages which support OOP. The discovery of the template language limitations has taken time, but been overcome so far.
Or course, there’s nothing stopping you from generating the class in the AppGen as you go along and having the source files open in an editor on other monitors. Notepad++ auto reloads changed files and its possible to have multiple instances of notepad open at the same time.
But its aimed at getting newbies to class writing, up to speed very very quickly.
Ditching one option from the ClassWriting template, the option to list all methods and their overloaded parameters because it clutters the dropdown list box too much.
The image explains how the Field Options work in the dct and IDE data buttons with the inifile.
Problem is the value inside the inifile Display() for each level has to be unique, so a random number appended at the end of method name if duplicates in another class exists thats defined in this AppGen file, and/or the overloaded method friendly name has duplicates, common because all have a default() to kick things off.
Periods create a new level, each level had to be unique, so random number introduced solves that problem but it looks messy so not going to include the Populate All Methods button and random numbers, and its only really for editing many files in the dct.
1 dct file is the data for 1 class or 1 class method and all overloads unless dictated by the variable’s field options.
If the option is used, the variable(s) are defined in the correct overloaded method procedure(s).
If the option is not used on all variables, the variable is defined in each overloaded method procedure.
So mix and matching can take place.
Anyway got to try these things…
