Any help with this...

[zph]

Good day all!

I've hit a road block in my routine and I can't seem to identify the issue.

When I run the attached routine (in model space only) for layouts 1 through 4, the export to the text file is good.

But when the crossing window includes layouts 1 through 5, the export data gets messed up.

The DESC variable (at the end of each line of the export text file) gets replaced by the cable number.

Any ideas?

Thanks!

~Z

[hencoop]

Hi zph,

Right off I see that you speak of "Layouts" in Model Space.  Layouts, the tabs in paper space other than "Model" do not exist in model space.  Do you mean something else by "Layouts" in model space?

[Kent1Cooper]

[@hencoop, if you open the drawing, it's clear that they're cabling or circuiting layouts -- it's not about the AutoCAD drawing element.]

That's a heck of a lot of code to try to wade through.  First things to check:  Does it work if you try just Layout 5 by itself?  Or if you try just 2 through 5, or some other combination of some but not all of them?  In other words, can you narrow down whether it might be something about the particular set of drawing entities in Layout 5, or perhaps about exceeding some quantity limit?  It might help to focus in on what to look for.

[hencoop]

Thanks for clearing that up Kent.

[zph]

Hi Kent!

Yes, it is a lot of code; I've been working it for a while.  I've also been trying to route out this issue, but to no avail.

And to answer your question....

Selecting 1 through 5, the error occurs.

Selecting:  1, 2, 3, 4, 5, no error.

Selecting:  2 - 5, 3 - 5, 4 - 5, no error.

Selecting:  1 - 2, 1 - 3, 1 - 4, no error.

I think there is an issue with the way the routine handles rotated text OR lwpolylines, but I am unable to find any errors.

EDIT:  Also, when I say "error"....the code isn't broken.  The routine loads, executes and runs to completion successfully.  The "error" is that under some condition, data is being overwritten by other data groups.

EDIT2:  Also, if you wish to try the routine yourself, you'll need alter the fPath variable so the routine knows where to generate the text file.

EDIT3:  You mention quantity limits.  What quantity limits?

[zph]

Additional data....

I moved 4 and 5 out of the way and replicated the 1st 3 layouts to make 1 - 6.  This makes it so there are no longer LWPOLYLINES or rotated text in the selection set.  ...the error occurs.

(the numbers at the end is the quantity of the items (lines) that should show up in the export file)

Selecting 1 - 2: no error      175

Selecting 1 - 3: no error       255 

Selecting 1 - 4: no error        334 

Selecting 1 - 5: error occurs  430

Selecting 1 - 6: error occurs  510

Selecting 2 - 6: error occurs  431

Selecting 3 - 6: no error       335

Selecting 4 - 6: no error       255

Selecting 5 - 6: no error       176

Going to see if there is a defined cutoff for the quantity...

[zph]

Selecting 1 - 2: no error      175

Selecting 1 - 3: no error       255 

Selecting 1 - 4: no error        334 

Selecting 1 - 5: error occurs  430

Selecting 1 - 6: error occurs  510

Selecting 2 - 6: error occurs  431

Selecting 3 - 6: no error       335

Selecting 4 - 6: no error       255

Selecting 5 - 6: no error       176

----

After doing all these tests...the routine doesn't run to completion, but hangs now.  Sounds like it could be a memory issue.

I closed the drawing file and reopened it and it is back to running to completion.

[zph]

Selecting 1 - 4: no error        334

Selecting 1 - 5: error occurs  430

Selecting 1 - 6: error occurs  510

Selecting 2 - 6: error occurs  431

Selecting 3 - 6: no error       335

-----------

(using selection 1 - 4, + parts of 5)

Selection, 335 entities: error

Selection, 336 entities: error

Selection, 338 entities: error

Selection, 340 entities: error

Selection, 346 entities: error

Selection, 358 entities: error

Selection, 382 entities: error

On a side note, the routine quits it there aren't any cables within the layout...need to fix that.

...Fixed in the attached routine...

(using selection 3 - 6, + parts of 2)

Selection, 336 entities: error

Selection, 337 entities: error

Selection, 343 entities: error

Selection, 383 entities: error

-------

Another wrench into the mix.  When I selected from the edge of the empty layout 2 to the far edge of layout 6...the error occurred.  3 to 6...no error.  Same quantity of entities 😕

[hencoop]

I thought I remembered something about this. I did a search and found this: "AutoCAD only maintains 128 global and static selection sets.".  Selections set limits may have something to do with your testing issues and maybe even the routine itself.  You can read the full article from which the quote was extracted here.

[zph]

See the attached .dwg file.

(selection is now the bottom section, minimal entities)

Selection 1-4: no error

Selection 1-5: DESC variable overwritten with cNo value

Selection 1-6: DESC variable overwritten with cNo value

Selection 1-7: DESC variable overwritten with cNo value

Selection 1-8: DESC variable overwritten with cNo value

Selection 1-9: DESC variable overwritten with cNo value

Selection 1-10: DESC variable overwritten with cNo value

Selection 1-11: DESC variable overwritten with cNo value + variables RK1 and RK2 overwritten (alternating) with EQPT entity value...you may need to look at the text file to understand.

...this error combination continues through to layouts 21 and I stopped there.

[zph]

Hi hencoop,

Thank you for your thoughts on the matter.

My routine generates much fewer than the max number of selection sets, so this shouldn't be a problem 🙂

A while back I was working a drawing that was nearing the max number of layout tabs though.  Switching between layout tabs would take about 5 seconds.  An exercise in patience, that was.

[hencoop]

While you are testing you create and recreate selections sets.  I thought it might be that AutoCAD is counting every selection set you have created since you started your session and that is why you are getting the different results after lots of testing.

[zph]

Oh, you might be right on this.  However, I intentionally clear all the selection set variables, at best, after I am done using them, and if not that at least at the end of the routine.

Hmmm.....

[Kent1Cooper]

---

@zph wrote:

.... 

Selecting 1 through 5, the error occurs.

Selecting:  1, 2, 3, 4, 5, no error.

Selecting:  2 - 5, 3 - 5, 4 - 5, no error.

Selecting:  1 - 2, 1 - 3, 1 - 4, no error.

.... 

EDIT3:  You mention quantity limits.  What quantity limits?

---

In addition to the possibilities already discussed that a limit on selection sets or variables could be the problem, could there be a limit on how long a list of things it can handle?

Instead of putting every eventual line in the resulting file into a list:

		(setq cDlist (cons (list (strcat
			rNo ", "
				cCl ", "
					RK1 ", "
					EL1 ", "
					HN1 ", "
					PORT1 ", "
						cTc ", "
							cNo ", "
								RK2 ", "
								EL2 ", "
								HN2 ", "
								PORT2 ", "
									MISC1 ", "
										MISC2 ", "
											DESC
		)) cDlist)) ;setq

and then writing each of them out to the file at the end, opening and closing the tFile for every one individually:

(foreach cD cDlist 
	(progn 
	(setq tFile (open tFpath "a"))
	(write-line (car cD) tFile)
	(close tFile)
	) ;progn
) ;foreach

try skipping the list altogether, opening tFile for appending once at the beginning and not closing it until after all this, and writing each line to the file as it's generated, rather than putting it into a list:

		(write-line (strcat ; in place of (setq cDlist (cons (list 
			rNo ", "
				cCl ", "
					RK1 ", "
					EL1 ", "
					HN1 ", "
					PORT1 ", "
						cTc ", "
							cNo ", "
								RK2 ", "
								EL2 ", "
								HN2 ", "
								PORT2 ", "
									MISC1 ", "
										MISC2 ", "
											DESC
		) tfile) ;write-line ; in place of  ) cDlist)

If I've mis-read something about how it works, and you really do need that list format, you might also try simplifying it by not making a list of lists with each sub-list containing one item [a text string], but simply a list of "top level" text strings, directly:

  (setq cDlist (cons (strcat ; without the (list) wrapper
    ....
  ) cDlist)) ;setq -- single right parenthesis at beginning, closing only (strcat) function

 and then at the end, write each text string directly, rather than needing to pull each text string out of its little sub-list:

(foreach cD cDlist 
	(progn 
	(setq tFile (open tFpath "a"))
	(write-line cD tFile); without the (car) wrapper
	(close tFile)
	) ;progn
) ;foreach

 but if viable, I would still suggest opening tFile once at the beginning and closing it once after all these things have been written to it.

[hencoop]

Kent,

I have not been following the coding discussion as it is already in your very capable hands; however, I have constructed some very long lists without any problems. In some cases Autolisp will throw an error and tell me I've exceeded something or another (I can't remember exactly what or the exact circumstance) but it does tell me I have "exceeded" whatever.  Without an error message indicating that I doubt that is the problem; although, it still could be.

I have had issues with the lengths of strings constructed with (STRCAT ...) in some cases.  I have found that they can be very long if they are purely in memory and can even be written to file but trying to apply them to to some uses (which I also can't remember exactly) will cause an error and failure because they exceed the allowable string length of 132 in some cases.

Trying to select too many items in a dialog listbox will also fail but I think that list length limitation is part of the DCL.

[zph]

Kent,

I've incorporated your ideas into the routine (the updated is attached).  It seems to be running faster, but the errors still persist.

I am reminded that if the crossing window ONLY includes one layout at a time, the routine works.

Using the initial crossing window, I could create a selection set containing all the layout 'lwpolylines'.

Write the text file and open it.

I could loop through this selection set.  For each entity (polyline), compute the boundary box to generate new crossing-window points and call this routine to export the data to the text file.  Looping proceeds to the end of the initial polyline selection set.

Close the text file.

---

Sounds like I'll need an overall .lsp file with the initial crossing window and loop code.  Inside the loop call a .scr file that calls CABLE_OUT for each loop iteration.

Am I missing anything obvious?

[zph]

I was unable to make my previous plan function so I did some additional testing.

I started testing to see if the horizontal distance of the initial crossing window had anything to do with the error.

I've attached new .dwg and .lsp files.

Minimal selection set (2 cables).

...171 inches to the right from the 1st selection point = no error.

...171.5 inches to the right from the 1st selection point = error.

Any ideas?

[zph]

I did some additional testing with the ssget function.

My routine uses a crossing window like so:

(ssget "_C" pt1 pt2 '((....

I tried this:

(ssget '((....

which multiplied the errors.

It seems that using 'ssget' in different ways, in my routine, produces different results even though the selection sets generated by 'ssget' are identical.

My question is - am I able to view the AutoCAD, SSGET function AutoLISP code anywhere?