Welcome to Telelogic Product Support
  Home Downloads Knowledgebase Case Tracking Licensing Help Telelogic Passport
Telelogic DOORS (steve huntington)
Decrease font size
Increase font size
Topic Title: DXL environment
Topic Summary:
Created On: 1-Apr-2003 23:39
Status: Post and Reply
Linear : Threading : Single : Branch
Search Topic Search Topic
Topic Tools Topic Tools
Quick Reply Quick Reply
Subscribe to this topic Subscribe to this topic
E-mail this topic to someone. E-mail this topic
Bookmark this topic Bookmark this topic
View similar topics View similar topics
View topic in raw text format. Print this topic.
 1-Apr-2003 23:39
User is offline View Users Profile Print this message


Jim Ward

Posts: 4
Joined: 1-Apr-2003

As a new DOORS user, I'm finding some difficulty learning about DXL. For example, if I'm in a DOORS module and pull down the Help menu, I see a selection for "DXL Reference Manual". If I go to "Tools/Edit DXL" then pick the Help button from the edit window, I get the regular DOORS help and I can't choose the DXL manual! Am I doing something wrong here?

Is there another development environment or editor that works better than the built-in one? Having some search capability would be very useful. And I guess I'm spoiled by syntax-sensitive editors that know the language and highlight things for me.

Thanks.
Report this to a Moderator Report this to a Moderator
 2-Apr-2003 16:39
User is offline View Users Profile Print this message


Nandan Banodkar

Posts: 22
Joined: 1-Oct-2002

You could use one of the lightweight editors: EditPlus or Crimson Editor....

You will find the syntax files, auto-completion files for these are available, and you can also easily integrate DXL help such that hitting a hotkey will automatically load the DXL help page for current word.

The DXL interaction window is definitely not the place to edit large scripts.

Links:

http://www.editplus.com
http://www.crimsoneditor.com/

and a previous thread about editors:
http://www.telelogic.com/support/doorsers/forums/messageview.cfm?catid=17&threadid=689&highlight_key=y&keyword1=editor

-------------------------

Nandan Banodkar

(nandanbanodkar@hotmail.com)
Report this to a Moderator Report this to a Moderator
 3-Apr-2003 00:29
User is offline View Users Profile Print this message


Louie Landale

Posts: 2070
Joined: 12-Sep-2002

Yes, I'd say "Help" on the DXL window should bring up DXL help, but it doesn't. Hey! The old version of DOORS offered NO buttons for getting to the DXL help; you had to create a shortcut outside of DOORS yourself. So at least they are coming along...

I'm SURE I've written more DXL code using the DXL window than anybody in the world; at least outside QSS/Telelogic. Its MUCH better than the punch-cards I started on (a few years ago...). I'm now using Crimson editor and like it better, but would no doubt like it a LOT better if I knew how to use its real capabilities.

In the DXL window I'll type a single line:
#include <c:/MyPath/MyFile.dxl>
to run and test the code I'm editing with Crimson.

- Louie
Report this to a Moderator Report this to a Moderator
 3-Apr-2003 12:49
User is offline View Users Profile Print this message


Tony Goodman

Posts: 1098
Joined: 12-Sep-2002

I use Crimson Editor too.
Another way to run your commands is to send the dxl script to DOORS for execution directly from Crimson.

A word of warning here. Your dxl script will need to set up your current folder/project and open modules explicitly as you are not running the script in the context of an open module.

To do this you need to start the DXL server by inserting the following in startup.dxl:
//pragma splashMessage,"Initialising DXL Server..."
initDXLServer server 5093

In Crimson Editor, add the following to the preferences->user tools setup:
Menu Text: Run DXL
Command: C:\Program Files\Telelogic\DOORS 6\bin\dxlipf.exe
Argument: $(FilePath)
Check the 8:3 filename.

Hot Key: CTRL-R

Write your script in Crimson, then hitting ctrl-r will save and run the script in doors. Easy.



-------------------------
Tony Goodman
http://www.smartdxl.com
Report this to a Moderator Report this to a Moderator
 12-May-2003 13:57
User is offline View Users Profile Print this message


Arne Styve

Posts: 7
Joined: 9-May-2003

Hi,

Sorry to enter this thread so late. Just recently read it.

Are there no DXL-tools/IDEs/Enviromnets that support any VBA-features like code-completion, and debugging features ?

How do people debug their DXL-scripts ?

Regards
Arne Styve
Report this to a Moderator Report this to a Moderator
 12-May-2003 18:37
User is offline View Users Profile Print this message


Michael Sutherland

Posts: 248
Joined: 13-Sep-2002

Arne,

We debug DXL scripts the same way people debugged software before VBA and other IDEs came along.

DXL will return a line number of the first syntax error it finds. This is usually informative, but if the error is caused by string or bracket mismatches, the line number might not be the exact place the error is. DXL sometimes return an error on a line that is one greater than the number of lines of code, which is (almost) always a bracket mismatch. Avoid string "" mismatches at all costs, as they are difficult to find.

The error "incorrectly concatenated tokens" is a catch-all for "you did something wrong, try again."

Other than that, when I get into trouble I put "print" statements in and around the problem area, and analyze the contents of variables. Check out the debug() routine in the D6 example code <example/circlinks.dxl> for an idea of how to build in print based debugging statements into complex code.

As the previous posts indicate, using a modern editor with syntax highlighting is helpful. I use http://www.ultraedit.com

Good luck!

-------------------------
Michael Sutherland
michael@galactic-solutions.com
http://galactic-solutions.com
Report this to a Moderator Report this to a Moderator
 12-May-2003 23:02
User is offline View Users Profile Print this message


Louie Landale

Posts: 2070
Joined: 12-Sep-2002

The bracket and quote mismatch typos typically result in from 50 to 8000 DXL errors. If you get that many ... go to the first error. Look for mismatched pairs of double-quotes "", and mismatched brackets (){}[], LOOKING FROM THAT POINT UPWARD. Expect to find it quickly. When you find a mismatch fix it, stop looking, and re-interpret the DXL again.

As far as debugging goes: when I write a true function (take inputs, calculate outputs) I just write a quick driver for it and test it itself. Usually I code with key print statements embedded right from the beginning; and comment them out after seeing that it works. Complicated functions are quite a bit trickier. I usually just implement them in phases: [1] Is the dialog box stable [2] Did I find everything I'm supposed to modify [3] Does the function work on the trivial or extreme cases. Finally, does it actually work.

This develop in stages works primarily because I don't spend much time "designing" these relatively small scripts. I get a good idea what I want to do and "develop" as I'm coding. The other reason it works is because the actual "meat" of the scripts is usually pretty small in size and complexity, when compared to the relatively simple but tedius work of organizing a dialog, gathering the input, and presenting the output. I once had a 3-page script that had only 8 lines of action code in it.

- Louie

Kids these days; need "code completers" and "code debuggers" and "syntax highlighters" just to write some code. Why when I was your age... You know, before word processors people used to write letters by hand and write novels with a typewriter. New tools are convenient but YOU still need to know what you want to create, create it, and test it. Too much emphasis today is on how to use a tool (e.g. a calculator) and too little on actual skills (e.g. how to divide). But I digress...
Report this to a Moderator Report this to a Moderator
 13-May-2003 07:49
User is offline View Users Profile Print this message


Arne Styve

Posts: 7
Joined: 9-May-2003

Thanks Michael and Louie !

The syntax errors is OK. Works fine. What I'm missing is at least the possibillity to step through the code, a feature that have been available in most SW-development tools since way back (long before syntax highlighting and code completion, Louie....). Adding print-statements works off course, but when trying to figure out a script someone else have written (like the Word-export/report script), you cannot add print statements all over to quikly figure out the basic flow.

As for your last comment Louie, "Kids these days; need "code completers" and "code debuggers" ........", yes, it is quite possible to build houses using wooden nails and bare hands in the year 2003 too.....but do you see anyone doing it ?

Thanks again for your input. Much appreciated!

Regards
Arne Styve
Report this to a Moderator Report this to a Moderator
 13-May-2003 19:43
User is offline View Users Profile Print this message


Michael Sutherland

Posts: 248
Joined: 13-Sep-2002

Arne,

If you are trying to debug the Word Exporter, I sometimes use a modified version of the checkRes() function that takes an extra parameter. The content of the extra parameter can be used to indicate which word Property or Method was accessed, or where in the DXL it was accessed. This is, of course, just a variation on adding print statements, but it can save the day when all else fails.

As for "yes, it is quite possible to build houses using wooden nails and bare hands in the year 2003 too.....but do you see anyone doing it ?" Perhaps, the Amish? The analogy is not to be taken too lightly, because some programmers do pride themselves on working well in difficult environments (machine code, etc.).

We all wish there were better debugging methods in the proprietary DXL language. We've been asking for them for years. Those of us who have been working in DXL for any length of time just get used to it and stop asking. I've had programmers on my team quit because programming in DXL isn't like VBA. I don't miss them, and have upgraded my interview process to help determine who is a suitable candidate for Amish programming.

The answer from Telelogic always is "wait for our next-generation product." We're waiting....

-------------------------
Michael Sutherland
michael@galactic-solutions.com
http://galactic-solutions.com
Report this to a Moderator Report this to a Moderator
 13-May-2003 22:19
User is offline View Users Profile Print this message


Louie Landale

Posts: 2070
Joined: 12-Sep-2002

I didn't express my point clearly. Someone who knows what they are doing can build a house with wooden nails and bare hands BETTER than some clown like me who's been to school and knows how to use a laser measure, mind-reading buzz saw, and anti-gravity supporters. Shakespear can write a better novel with pen and paper than I can with MS-Word.

Tools-expertise is no substitute for skills-expertise.

Anyway, I don't have any problem finding the bugs in my relatively simple scripts, and certainly don't need some sort of "debugger" to figure out what the Word Exporter does. Which I did a few years ago, added numerous serious improvements, and could export 99% release-picture-perfect documents straight from DOORS.

- Louie
Report this to a Moderator Report this to a Moderator
 14-May-2003 08:47
User is offline View Users Profile Print this message


Arne Styve

Posts: 7
Joined: 9-May-2003

Hi Louie,

Please do not missunderstand me. I do really agree with your point about Shakespear and Word. A tool is just a tool and nothing but a tool. BUT beeing a professional Systems Designer I absolutely prefere to have a tool with some usefull features, like debugging, instead of a tool that does not support it. If you were given the choice between a DXL IDE with an integrated debugger, and an DXL-IDE without, and the tools were identical otherwise, I would be surprised if you didn't select the one with debugging features.

Anyway, lets leave it here.

If I migth be so bold to ask you a technical question regarding DXL and the Word-script. I'm doing some modifications to it to be able to generate a reqirements spec. where I would like the Object ID in the margin to the left of the text, something like this:

[FEAT12] The system shall be able to......

So I dived into the wordDumpBodyVBA(), copied it and renamed it to wordDumpRequirementVBA(), did the same with pasteAndApplyStyleToAttribute() which I renamed to pasteAndApplyStyleToRequirement(). Now to the sentence I need to change:

fullRtf = makeFullRTFWithStyle(richTextWithOle o.attrName, getStyleForAttribute(o,attrName), true)

I do want to keep any formatting in the "Object Text"-attribute, so I guess I have to stick to the richText-feature. Hence I tried the following:

string fullString = richtext_identifier(o) "\t" richTextWithOle( o.attrName )
fullRtf = makeFullRTFWithStyle( fullString, getStyleForAttribute(o,attrName), true)

which results in DOORS getting an "Unexpected Error" with a screen dump. I then tried:

string fullString = richtext_identifier(o) richText("\t") richTextWithOle( o.attrName )

resulting in the same error. I've also tried other combinations without success. And ever no and then, DOORS just terminates when trying to run the script.

I would appreciate if you would be so kind and share with me your thoughts about this problem.

Regards
Arne Styve

Report this to a Moderator Report this to a Moderator
 14-May-2003 08:56
User is offline View Users Profile Print this message


Arne Styve

Posts: 7
Joined: 9-May-2003

Hi Michael,

Thanks for your feedback. I'll study the checkRes() :-)

As for the discussion I've seam to have triggered regarding Amish programming, I've given Louie a hopefully clearifying answer of my real opinion, that might have not been too clear in my first postings.

Thanks!

Regards
Arne Styve
Report this to a Moderator Report this to a Moderator
 17-Jul-2007 00:11
User is offline View Users Profile Print this message


Georges Reti

Posts: 4
Joined: 31-Jan-2007

I find developing direct from a modern tool pretty useful. I managed to get crimson and PSPad to work with dxlipf.exe. However this method seems to have a limit of about 2000 characters (2048?). The same script will crash on dxlipf.exe while working in the DXL editing tool embeded in DOORS. (for example a file with a 2000+ character comment will not work). A work around is to run a file that does only an include from your favorite editor. Includes don't seem to be affected by this bug.

-------------------------
Georges Reti

Requirements engineering, Systems engineering
CAE
Report this to a Moderator Report this to a Moderator
 17-Jul-2007 13:46
User is offline View Users Profile Print this message


David Pechacek

Posts: 674
Joined: 5-Dec-2006

Question for you Tony.

In Crimson Editor, I followed your instructions to get a script to run. I also checked the "Capture Output" option.

I tried running just an include file to test it out and got

---------- Capture Output ----------
> "C:\Program Files\Telelogic\DOORS_8.1\bin\dxlipf.exe" H:\DXLSCR~1\COMMON~1.INC
API error: File 0.000000 is too large to send using V1 protocol; consider using V2.

> Terminated with exit code 1.

How do I use "V2" protocol?

-------------------------
David Pechacek
AAI Services Textron
dpechacek@sc-aaicorp.com
David.Pechacek@gmail.com
Report this to a Moderator Report this to a Moderator
 17-Jul-2007 15:51
User is offline View Users Profile Print this message


Tony Goodman

Posts: 1098
Joined: 12-Sep-2002

Haven't used the DXL server for a few years, so I am a little rusty.

You could try using void initDxlServerV2(IPC) instead. This is of cource undocumented and I haven't tried it.

Let us know if it works.

-------------------------
Tony Goodman
http://www.smartdxl.com
Report this to a Moderator Report this to a Moderator
 17-Jul-2007 16:14
User is offline View Users Profile Print this message


David Pechacek

Posts: 674
Joined: 5-Dec-2006

Still get the same error. Thanks though.

-------------------------
David Pechacek
AAI Services Textron
dpechacek@sc-aaicorp.com
David.Pechacek@gmail.com
Report this to a Moderator Report this to a Moderator
 18-Jul-2007 00:46
User is offline View Users Profile Print this message


Louie Landale

Posts: 2070
Joined: 12-Sep-2002

It must be just me. But just about all my scripts are context sensitive, such as a current module or a current folder. Out of 180 or so scripts I have, only a couple hard-code a project or module name as context. It thus wouldn't make sense for me to 'send' DOORS a dxl script from an editor since the script would have to tell DOORS where to execute. No, I either edit DXL from a module or a folder, #include the script, and 'run' from DXL. The editor only saves it. If I want to debug and try different contexts I just navitage around and then 'run' again.

- Louie
Report this to a Moderator Report this to a Moderator
 18-Jul-2007 10:25
User is offline View Users Profile Print this message


Richard Good

Posts: 152
Joined: 22-Mar-2005

Mr Landales right about the context. My solution is to have a button that sends the active file wrapped in an include statment to the clipboard. It then looks for a dxl editor window - if it finds one it pastes the include statment in and presses the run button. If there is no dxl window open then the include statment is still in the clipboard so I open a dxl window manually then paste the include statement and press run, I came to the conclusion that thats about as automated as you can sensibly get. The dxllipf technique mentioned above also seems to be unreliable to say the least, ie it used to fall over sometimes and not others and I couldn't figure out why.

-------------------------
Regards,

Richard Good
Report this to a Moderator Report this to a Moderator
 19-Jul-2007 22:13
User is offline View Users Profile Print this message


Georges Reti

Posts: 4
Joined: 31-Jan-2007

I agree with you that at the end, most scripts are context sensitive. But during the development of a new script, you usually work on a test module which is hard coded. Once the script is stable enough on the test module, I make the script context sensitive, at the same time I'm binding it to a menu. To quote Louie, Tools-expertise is no substitute for skills-expertise and I really agree with that, but especially on big scripts, I really appreciate to have an advanced development environment and not having to copy paste every time my code in DOORS editor, or select a menu in DOORS. Wouldn't the Egyptians have built more / bigger pyramids if they had better tools? Or maybe it's just me being lazy

-------------------------
Georges Reti

Requirements engineering, Systems engineering
CAE
Report this to a Moderator Report this to a Moderator
 2-Aug-2007 14:58
User is offline View Users Profile Print this message


Bryan Kelly

Posts: 3
Joined: 2-Aug-2007

I am a very notics DXL user.  Does anyone have simple instructions on useing Ultraedit as by DXL editor?
Thank you,
BK

Report this to a Moderator Report this to a Moderator
Statistics
20925 users are registered to the Telelogic DOORS forum.
There are currently 1 users logged in.
The most users ever online was 15 on 15-Jan-2009 at 16:36.
There are currently 0 guests browsing this forum, which makes a total of 1 users using this forum.
You have posted 0 messages to this forum. 0 overall.

FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.