Length of DIESEL macro

I'm building a DIESEL macro for a palette button and I have run into a problem.

As usual I build up my macros from a concatenation of smaller macros and up to now I have not had a problem. This time the macro is a long one and when I add the last part it doesn't work any more.

The macro gets the drawing extents and saves them to two environment variables. It then inserts attributed blocks on the coordinates stored in each of the environment variables. Then using attribute extraction it writes the coordinates to a text file. This file will be later used by an external app.

Using this code the macro works fine up to inserting the two blocks

^C^C_setenv;Trans1;$M=$(getvar,extmin);-insert;passpunkt;$M=$(getenv,trans1);1;;0;_setenv;Trans2;$M=$(getvar,extmax);-insert;passpunkt;$M=$(getenv,trans2);1;;0;

If I afterwards use the following code to write the coordintes to the text file it works fine

^C^C-ATTEXT;SDF;"J:/Planung/passpunkt_vorlage.txt";"J:/Planung/TransDatei.txt";y;

But when I concatenate them both together in this code it no longer works

^C^C_setenv;Trans1;$M=$(getvar,extmin);-insert;passpunkt;$M=$(getenv,trans1);1;;0;_setenv;Trans2;$M=$(getvar,extmax);-insert;passpunkt;$M=$(getenv,trans2);1;;0;-ATTEXT;SDF;"J:/Planung/passpunkt_vorlage.txt";"J:/Planung/TransDatei.txt";y;

Is there a maximum length for a macro on a palette button? The maximum length of a DIESEL expression is 460 and I have only half that amount here.

I see you have civ3d you can write lisp code to a menu etc this may be simpler than using diesel just do a few (step1code)(step2code)(step3code) or I use (load "step1")(load "step2")(load "step3")

First Impression. I haven't really looked at the macro yet but I have macros way longer than that (though according to Ralph Grabowski there is a 79 or 255 character limit), how is it failing?, do you have macrotrace turned on?. I think it has something to do with setting and then reading the variables in the same macro. That is a difficult one to get working because the value isn't actually set untill the macro finishes, so getvar usually reads the old value (set the last time you ran the macro) rather than the current one. As an alternative you could use an attributed block with fields, you can read system variables as a field value, and just have the macro do the attext bit.

OK, I tried the macro, without success as you discovered. Try using "passpunktvorlage.txt" in place of "passpunkt_vorlage.txt", I think it is the diesel interpreter ,having problems with some characters. Obviously I have a different network, but it was failing on spaces and special characters, probably because of the quotes for the path names, diesel uses quotes to change the order in which strings are processed, and it looks like that is causing the problem.

Using a block with extmin and extmax in fields would probably be simpler.

@ BigAl,

Yup I have C3D but I'm writing this macro for LT. I have the whole thing covered in C3D with VBA routines, but I can't use them in LT.

@ steven,

The complete macro that doesn't work is 127 characters long. I'll check the length of the macro that does work and see if it is less than 79.

I'm using environment variables not system variables for storing the strings and they are populated from the drawing extents variables EXTMIN and EXTMAX.

The blocks that are inserted are attributed blocks with fields and I get their coordinates from the fields. I then use ATTEXT to write the coordinates to an ascii file.

The individual macros all work fine, so it would appear that the underscore in the attribute extraction template "passpunkt_vorlage.txt" is not causing a problem.

I have it all working now, but I have split the long macro into two shorter ones. What is strange is that I just cut off the end of the long macro and pasted it into a new macro, without modification, and it works.

I have it working in one macro ,

^C^C_setenv;Trans1;$M=$(getvar,extmin);-insert;passpunkt;$M=$(getenv,trans1);1;;0;_setenv;Trans2;$M=$(getvar,extmax);-insert;passpunkt;$M=$(getenv,trans2);1;;0;_ATTEXT;SDF;"P:/ste/test.txt";"P:/ste/TransDatei.txt";y;

Now it's failing again

And you can store EXTMIN and EXTMAX directly as a field value in an attribute (well 2 attributes) so all you need do is ATTEXT

Passpunkt.dwg

That's a good tip about the system variables in fields of block attributes. But... for certain drawings it will not be possible to use drawing extents as the numbers are huge and in that case two blocks are inserted manually and they are then used for the attribute extraction. I'll check out the idea though and see if I can get it to work.

OK try this (change your paths to suit)

^C^C_setenv;Trans1;$M=$(getvar,extmin);_setenv;Trans2;"$M=$(getenv,trans1)";-insert;passpunkt;""$M=$(getvar,extmax)"";1;;0;-insert;passpunkt;"""$M=$(getenv,trans2)""";1;;0;_ATTEXT;SDF;"P:/ST_E/test.txt";"P:/ST_E/TransDatei.txt";y;

It changes the order of the diesel macro slightly but it works consistently here, the quotes around the later diesel functions alter the evaluation sequence of the macro.

I incorporated your ideas but it still fails in exactly the same place as itoriginally did. It takes the attribute template name OK but doesn't find the extraction file. The path it is suggesting is the folder where the drawing is. I tried it on another drawing in another folder and it does the same. Here's the text window text produced:

Command: -ATTEXT

Enter extraction type or enable object selection [Cdf/Sdf/Dxf/Objects] : SDF

Enter template file name : J:/Planung/Transformation/passpunkt_vorlage.txt

Enter extract file name : J:/Planung/

"J:\Planung\.txt": Invalid file name.

The template and extract files cannot be the same.

Enter extract file name : J:\Ben\Daten Transformation\Grünbach\Grünbach_23_RD83.txt already exists, do you want to replace it? [Yes/No] :

Command: -ATTEXT

Enter extraction type or enable object selection [Cdf/Sdf/Dxf/Objects] : ??

Invalid option keyword.

Enter extraction type or enable object selection [Cdf/Sdf/Dxf/Objects] :

I've tried with extra quotation marks but still can't get it to work.

Do you have macrotrace set to 1, it's not easy to follow but it does give some clues as to what is going wrong. If you could copy the complete command history for the macro it might be easier to see what is going on.

I had MACROTRACE on so nI set to zero restarted LT and reset it to 1. Attached is a text file with the output. It's failing at lines 50 and 51. Right at the end I've put the macro that was used to create the trace.

Macro error trace.txt

Try with just a single quote on that last path (the extraction output file).

This is wierd, it worked yesterday, it even worked this morning, I changed the path to a longer version as a check and it failed to work, so I changed it back to the short version and it now still fails, even closing Autocad and restarting it won't run.

I think there might be a bug in there somewhere.

I got it running again, and it kept stopping, I have narrowed it down to zoom-extents. The macro is happily working but after zooming to extents it stops, and this is repeatable - at least it is here, changing the macro looked as though it was causing problems, and that the changes weren't being updated, but zoom extents definately kills this macro, exiting and restarting and it works again until zooming to extents. Very strange.

Is there a reason that you need to put the extents into a variable and then read that same information back into the same macro

^C^C-insert;passpunkt;$M=$(getvar,extmin);1;;0;-insert;passpunkt;$(getvar,extmax);1;;0;_ATTEXT;SDF;"P:0-Steven/TEST_1/test.txt";"P:/0-Steven/TEST_1/TransDatei.txt";y;

No. At that point it was the way I was getting the values of EXTMIN and EXTMAX. I tried leaving out the zoom extents bit, but it didn't change anything here.

I've been out all morning and only just got back in. While I was driving I gave it a bit of thought and I'm going to try your idea. Insert a single block in the centre of the area of interest; give the block two attributes with EXTMIN and EXTMAX as field values; extract the attributes to an ascii file. Leaving out zoom extents was just a little extra that can be left out.

Occasionally there is the situation where the distance between EXTMIN and EXTMAX is several hundred thousand kilometres and in that case the results are very bad, I know cos I tried it. We are dealing with the ETRS and RD83 coordinate systems. In those cases two blocks are inserted in the area of interest and their positions read into an ascii file using the same snippet of a macro that I was using here. But if I'm going to have to have two different macros anyway, they don't need to be the same. In MAP and C3D there is an affine transformation to do all this, but not in LT.

This latest macro works over larger distances than that, and with zoom extents, well it did 2 minutes ago! who knows how long it will last

Thanks for that steven .

I've had a rush job to get out which meant that I had to drop this for a while. But I tried out your macro and it works fine. I've been trying to break it all morning but it didn't break. Well done that man.

The problem over the large distances is not the maths its all to do with translating coordinates from one coordinate system into another. Each coordinate system is on its own ellipsoid (sphere) and they are not concentric, which means you can't do a simple shift and rotate alignment. The coordinates have to be distorted (stretched and shrunk) to fit them on the target system. LT doesn't have an affine transformation function (as MAP and Civil do) which will do the distortion, so it has to be a workaround by doing transformations on small areas. It fits the purpose here and gets the job done in LT.

Once again many thanks for your help.