Topic Title

Hi Pietro
Some thoughts on XBuilder.( Pietro Moras's Classic Dcal program editor).

The menu item 'S3 *DCO_MGR' should be placed before 'F6 Link'. Better still when the active file is a module file then the Link option should not be availlable.
If the active file is a program file then then dcal will flag an error if the necessary .obg files have not been added, (I was surprised that XBuilder created a dcx file from a module. My version of DCAL gives an error if you try to run dcl.exe on a module file).

Since there can only be one program file XBuilder should use this to control the project. A bit of thought on F1 Init and F2 Open. The programmer will need to use the compile option for both programs and modules. Creating new and open existing in both cases. So if the 'S3 *DCO_MGR' allowed the selection of .obj files and checks to see that the first file in the list is derived from a program file this would solve the problem.

Is it necessary to create an ini file for every program and module?
Compiling from within my preferred editor PSPad my version of dcal accepts
#INCLUDE 'dwtruss.inc' where dwtruss.inc is an include file in the program directory. The version used by XBuilder will not accept this. You have to place it in a sub-directory and use the relative path method.

Another surprise is the Module statement must not have a space before it. It apparently compiles from within XBuilder but no .obj file is created. I will have to research the versions of dcal.

I had placed XBuilder in a sub-directory of E:tempry but used source code in
E:\DCAL\DrwTruss. After a few 'experiments' XBuilder gave the message 'XBuilder has found itself inexplicably moved here E:Dcal\DrwTruss. OK to let XBuilder recover..'. This I accepted. Result another lot of duplicated sub-directories 'Xlab' and 'XStore'.

I did successfully compile and link.
More experimenting required

Regards
Rod Walker

Hello Pietro,
oops! I meant .dco files (not .obj).

My point about ini files. Since a DCAL program must have a program file this controls every thing. Module files and inc files are optional. So surely one ini file for each project should be sufficient.

I realise that XBuilder is meant to be a 'total' environement; but for it to be accepted then it must improve on current practice. My current method is to use PSPad text editor for development.

I can have DataCAD open ready for instant testing of the .dcx program.
PSPad allows the running of Dos commands with output capture. It remembers these commands by placing them in an easy accessible list.
So it is simple to compile multiple modules, link to create the dcx file and test in DataCAD and return to editing because PSPad is still active. Plus multiple files can be open within PSPad.

DCC1.exe, DCC2.exe etc. stay in the DCAL directory. You must make it absolutely clear that Xbuilder requires USERS source code to be placed in the appropriate XBuilder folder. My experimenting has created Xstores all over the place. Very annoying.

This is enough for now I will continue experimenting

Regards
Rod Walker

[/url]

I have not moved XBuilder.dmx. The package is installed as per instructions.
Now I can only report what is happening as I use it and unless the project is in the XBuilder folder structure XBuilder will complain and create a new substructure.
For every source code file, whether it be a module or a program there is created an ini file.
So I will remove XBUILDER and do new install and see what happens.

Regards
Rod Walker

Well I removed all of XBuilder and down loaded again and Installed to E:\Tempry directory.
I installed XBuilder.DMX via DataCADs ToolBox drop down menu and XBuilder complained and duplicated the Xstore etc. as previously described.
So deleted everything . On examining DataCAD.ini the pathname for macros was set to E:\DCAL\DRWTRUSS.
Using the side bar Edit menu S9 to load XBuilder.dmx removed the error. On checking DataCAD.ini file the pathname for Macros was changed. Adding macros via DataCADs Dropdown toolbox does not change MACRO pathnames.

A bit late to continue; but XBuilder did not complain after reinstalling and using S9 to load XBuilder.dmx, so will keep you informed of progress.

By the way I am satisfied with the documentation for DCAL. I have an old manual and have found it easy to follow and use. Posts on forums and from Debug have been helpful.

Regards
Rod Walker

Loading XBuilder from Edit menu S9 Toolbox has solved a lot of problems. I can now change to my preferred text editor PSPad. Regarding text editors I think I would prefer to have it operate in a Windows 'Multiple' windows environment rather than have to close the editor before compilation.

Ok I have a program consisting of:
DrwTruss.dcs the program file which loads a custom include file.
Roofsym.dcs a Module file and SerialNo.DCS also a module file.

From XBuilder I F1 INIT_New and select DrwTruss.DCS, F3 Edit followed by F4 Compile (with success.) Checking the source directory no DrwTruss.DCO apparent; but there must be a dco file somewhere because trying F4 Link gave me the correct error messages that external files were missing.

So next step F2 Open and selected Roofsyms.dcs the Module file which successfully compiled (Ditto repeating process with Module SerialNo.dcs.
I now had 2 .dco files Roofsyms.dco and SerialNo.dco. At this point I wouls expect the 'Project' DrwTruss to be availlable for adding the DCO modules; but you have to re-open DrwTruss and re-compile before being able to run the Link option to create the .DCX file.

A better method might be to allow editing and compiling of DCS files to create the required .DCO files. Then use the *DCO-Mgr to add the files checking that the first file in the list is a 'Program' file, and the others that follow (if any) are modules. The linker DCL.exe will flag this anyway.

Should the Run option only run the application under development? It shows App.DCX if the user tracks to the source directory and selects DrwTruss.DCX (in this example) then the error of relocation occurs as described previously. A beginner may not realise that APP.dcx is the file under development.

Regards
Rod Walker

The basic task is understood.
My point is that if the 'program' file is edited and compiled correctly and then I edit a module file and compile this correctly, why should I need to recompile the program file? With XBuilder you always have to open the program file and compile it after making changes to module files.
Since a program file must always be first in a link list I would like to see the *.DCO-Mgr modified to cater for this.

Regarding the DCO-Mgr: I would remove the XBase Path text box which shows in my setup: 'E\TEMPRY\XBUILDER\XSTORE\XTOOLS\XLAB_MDL'. The user can not edit this so why show it? This points to the _MdLbr.txt file which contains the module list.
Similarly the Module text box serves no purpose since the item selected is shown by the ticked check box.

Small point, change the label of the 'drop' box to 'delete' or 'remove'. Initially I thought 'drop' meant drop it down the list.

On successful linking two identical DCX files are created APP.DCX and in my case DRWTRUSS.DCX. APP.DCX exists in the \TEMPRY\XBuilder folder whilst Drwtruss.DCX is in my source directory \DCAL\DRWTRUSS\. All ok.

The option F7 Run opens in the \TEMPRY\XBUILDER giving the user the choice of opening APP.DCX or XBUILDER.DMX. May be better if the Run option simply opened APP.DCX. Or have the run option open in the users directory showing the users dcx file.

It would be nice if on quitting the user macro you were returned to XBuilder.

Regards
Rod Walker




Regards
Rod Walker

Yes Peotro
I would be happy to look at your documentation.

I have solved one of my 'problems'. By opening my editor first and choosing its 'stay on top' option and then starting DataCAD - Xbuilder I can have my multiple source files open for editing and just use XBuilder to Compile and Link etc. That is ignore XBuilders Edit Function.

I will compose some thoughts on the development process at a later date.

Regards
Rod Walker

http://sourceforge.net/project/showfile ... p_id=58130

http://syn.sourceforge.net/manual/v2.1/ ... ghlighting


I think you can use this as it highlights and indents most of the old DCAL commands. You have to use Object Pascal and you can write code. DCAL IS the complete Pascal language missing only CASE (IF & ELSIF are the substitutes). It can open many files at the same time and do most of the things that you would want in a programing editor.

You can also write a script (dos batch file) to link, compile and copy the macro into DataCAD - ready to run in one step. I think the info on that is in the old manual and it still works with XP Pro anyhow.

A dedicated program would be nice but it has to at least work as well as this combination? And, I do agree that better documentation from DCLLC would be nice. I'm just now having time enough on my hands to where I might want to delve back into this to automate some of our processes that we use but probably no one else would ever want. DCAL Classic seems to fit the bill for this.

http://sourceforge.net/project/showfile ... p_id=58130

http://syn.sourceforge.net/manual/v2.1/ ... ghlighting


I think you can use this as it highlights and indents most of the old DCAL commands. You have to use Object Pascal and you can write code. DCAL IS the complete Pascal language missing only CASE (IF & ELSIF are the substitutes). It can open many files at the same time and do most of the things that you would want in a programing editor.

You can also write a script (dos batch file) to link, compile and copy the macro into DataCAD - ready to run in one step. I think the info on that is in the old manual and it still works with XP Pro anyhow.

A dedicated program would be nice but it has to at least work as well as this combination? And, I do agree that better documentation from DCLLC would be nice. I'm just now having time enough on my hands to where I might want to delve back into this to automate some of our processes that we use but probably no one else would ever want. DCAL Classic seems to fit the bill for this.