View Full Version : Why The #####?
TerribleTim
2007-04-25, 09:38 PM
So here's the dealio! I got his little dynamic block that has an attribute at one end, and at the other end it has an attribute who's value is the first attribute. Still trackin'? So why is it when I cut and paste the block from one drawing to another, I get ##### in the one attribute that is linked to the first one? Even if I change the first one's value, it still reads #####!?!?!?!? What up? Is this just the nature of the beast?
TerribleTim
2007-04-25, 09:39 PM
. . .Even if I change the first one's value, it still reads #####!?!?!?!? . . .
Forgot to mention, even after regen.
Chris.N
2007-04-25, 09:42 PM
did you search for "linked attributes" in this forum yet?
i think in the "fields" forum there's goodies to this subject as well...
TerribleTim
2007-04-25, 09:45 PM
I'll look into it. Thanks!
Mr Cory
2007-04-25, 11:51 PM
If you find a solution would be mind posting your answer back here just out of interest please?
CADDmanVA
2007-04-26, 12:46 AM
Call me REALLY old school, but using accelerator keys (CTRL+C, etc.) results in broken fingers in my book. When you need to send a block to another drawing, you WBLOCK it, period. If there is a linked attribute in the block, inserting it into other drawings the way you are could be the culprit, try WBLOCKing it to see what happens.
You would never guess how many times I had to trace errors in drawings back to people using accelerator keys improperly? We have an entire section of our CADD Standard manual dedicated to it.
Mr Cory
2007-04-26, 01:19 AM
Ouch, well guess i have broken fingers then, ACC/pention anyone else? ;)
CADDmanVA
2007-04-26, 02:14 AM
Ouch, well guess i have broken fingers then, ACC/pention anyone else? ;)Hmmm...that's not a bad idea actually :) Maybe we could work out a deal and both take early retirements? I won't tell if you won't. 8)
Mr Cory
2007-04-26, 02:21 AM
8) Hahaha i like the way you think!! Nar secret squirrel! 8) :veryevil:
Chris.N
2007-04-26, 12:07 PM
If you find a solution would be mind posting your answer back here just out of interest please?ha! you don't wanna search, do you? ;)
actually, there were solutions posted in those other threads... kind of...
Chris.N
2007-04-26, 12:10 PM
Call me REALLY old school, but using accelerator keys (CTRL+C, etc.) results in broken fingers in my book. When you need to send a block to another drawing, you WBLOCK it, period. If there is a linked attribute in the block, inserting it into other drawings the way you are could be the culprit, try WBLOCKing it to see what happens.
You would never guess how many times I had to trace errors in drawings back to people using accelerator keys improperly? We have an entire section of our CADD Standard manual dedicated to it.for a lot of DB's i agree as i've had the dreaded "######"'g (hehe) traced back to copy/paste actions, but have not had any issues with blocks that are linked to the Sheet Set Manager. i c/p callouts and titleblocks (if custom from template) all the time w/ no problem.
CADDmanVA
2007-04-26, 12:29 PM
for a lot of DB's i agree as i've had the dreaded "######"'g (hehe) traced back to copy/paste actions, but have not had any issues with blocks that are linked to the Sheet Set Manager. i c/p callouts and titleblocks (if custom from template) all the time w/ no problem.What you say is very true (as usual :p). The problem I have is when the COPY command becomes replaced with accelerator keys. I kid you not, a user gave me a file at 150 Meg with a corrupt block table one time. After cleaning the A$C blocks, purging, cleaning, purging and so on, the file came down to 10 Meg! :shock: I think it's amazing how badly accelerator keys can dork drawings!
Chris.N
2007-04-26, 12:42 PM
What you say is very true (as usual :p). The problem I have is when the COPY command becomes replaced with accelerator keys. I kid you not, a user gave me a file at 150 Meg with a corrupt block table one time. After cleaning the A$C blocks, purging, cleaning, purging and so on, the file came down to 10 Meg! :shock: I think it's amazing how badly accelerator keys can dork drawings!not to switch focus, cuz you're right, purge is not used enough, but for file size, is your user using partial saves? that will inflate drawings as well.
CADDmanVA
2007-04-26, 12:54 PM
not to switch focus, cuz you're right, purge is not used enough, but for file size, is your user using partial saves? that will inflate drawings as well.Thread hijacking on Augi forums? Never heard of it...
I thought about partial saves as a problem, but it wasn't. Honest to God, they used accelerator keys so much, the A$C blocks bloated the drawing that much. When I started I did a LIST of all block references in the drawing with names beginning with A$C and the resulting log file was 25 pages...at 8 point font!!!
Mr Cory
2007-04-26, 08:38 PM
To Chris, your right i was being lazy ;) Tehehehe.
To CADDManVA
Hijacking? O yes Chris will do that... ;)
25 PAGES GEZ!
To Everyone, i didnt realise the acc keys corrupted at all :shock:
Chris.N
2007-04-26, 08:39 PM
To Chris, your right i was being lazy ;) Tehehehe.
To CADDManVA
Hijacking? O yes Chris will do that... ;)
25 PAGES GEZ!
To Everyone, i didnt realise the acc keys corrupted at all :shock:it's not that they corrupt the file, it's the file size when one will willynilly copy/paste in a file vs. "copy" command on objects.
i only copy/paste between files...
Mr Cory
2007-04-26, 08:45 PM
Oh yeah, only between files not within the drawing itself. Why does it affect the file size?
Chris.N
2007-04-26, 09:06 PM
Oh yeah, only between files not within the drawing itself. Why does it affect the file size?it creates a 'temp' block for the paste action, and they don't delete themselves upon placement.
Mr Cory
2007-04-26, 09:11 PM
it creates a 'temp' block for the paste action, and they don't delete themselves upon placement.
I see, thats strange that it creates a temp block
Chris.N
2007-04-26, 09:31 PM
I see, thats strange that it creates a temp blockyeah, purge blocks in your file, then copy/paste a bunch, then go back and see the block list in the purge again....
Mr Cory
2007-04-26, 09:35 PM
:shock: :shock: :shock:
Jeebers! Huh here me thinking that they were created from manipulating DBs lol opps
So here's the dealio! I got his little dynamic block that has an attribute at one end, and at the other end it has an attribute who's value is the first attribute. Still trackin'? So why is it when I cut and paste the block from one drawing to another, I get ##### in the one attribute that is linked to the first one? Even if I change the first one's value, it still reads #####!?!?!?!? What up? Is this just the nature of the beast?Late to the party a usual, but this #### in a field indicates that the field value you're trying to link to AREN'T coming through. If you go back in to your BE and check your field (attribute with field in it) an error message will pop up that says that the value you were trying to link to is not valid or something.
That's all from my own experience, anyway. When you see #### in a field, it usually means that something didn't take and that it needs to be looked at again.
Mr Cory
2007-04-28, 03:56 AM
Yea, like when you are trying to get the distance and you link to the param
shinji130
2007-04-30, 05:58 PM
it creates a 'temp' block for the paste action, and they don't delete themselves upon placement.
Thanks for pointing that out. I learn something new today =)
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions Inc. All rights reserved.