CompuServe Thread

#Rel 12

11 messages in this thread
#33986From: mike mulveyFeb 21, 1992 1:06 PM
Hey guys ! Any idea yet as to when we can expect Release 12 ????? and especially when it will be available for the SUN SPARC platform ? We're getting really tired of having to work around Rel 11's PCNFS/XREF bug. You know, the one that causes 20 minute drawing file load times on PC's connected to SUN SPARCstations via PCNFS.
#34091From: Malcolm Davies [ADESK]Feb 22, 1992 12:16 AM
Mike: We have publicly stated our intention to deliver AutoCAD Release 12 for 386 and Sun SPARC in our Q3, that is before November 1992. Malcolm
#34195From: Peter K. SheerinFeb 22, 1992 4:54 PM
Whew! Two years again between releases. I'll bet it will be worth the wait, too. Let me put something bluntly, though: With two years between R11 & R12, I will scream bloody murder if it ships without a proper extention of VISRETAIN! I'm not kidding; it's that important. We won't be able to use XREF's if it's not extended to allow one to keep color changes to layers, period. Now, since everyone is keeping very tight lips about what's in R12, you may well have fixed this, and just not bragged about it. If so, please pardon the flame.
#34202From: Craig Sharp [Mem TM]Feb 22, 1992 5:51 PM
Peter: Yes, I think you're well on the way to public self flagilation and matrydom… either way, now, you're gonna get the OMF… if Autodesk listens… for a cause well executed. If they don't… for making a mess of yourself on the forum <wide grin>. Keep up the good work. The AYATOLLAHYOU
#34224From: Peter K. SheerinFeb 22, 1992 9:08 PM
I was thinking of warning Malcom that I'd pay him a personal visit to complain about VISRETAIN, if that's what it takes. Heck, if it helped, it'd be more than worth the 2+ hour round trip! <not kidding> Perhaps I can convince Malcom to come to the SFAUG's demo of WinACAD, and then the whole user's group can bug him about it; one by one, by….
#34290From: Malcolm Davies [ADESK]Feb 23, 1992 3:14 PM
Peter: Thanks for your message, I think I got it loud and clear. I will pass it on to John Lynch, he is the AutoCAD co-General Manager and is responsible for managing all the good stuff in R12. I am happy to attend another meeting, but you really need to talk to John. As of now, I do not know if your request was included, but if it was not, I will plan to leave town ahead of the announcement, thanks for the warning. Malcolm
#34303From: Peter K. SheerinFeb 23, 1992 5:41 PM
Hehehe. All kidding aside, if it *does* ship without that fix, then my visit will be to deliver all the letters from the letter writing campaing I start the day after delivery, personally. The letters will all ask for a R12 c1 bugfix more eagerly than Mark Burns ever did for R11 c3! Expect to see a thick stack. I think it's clear to most everyone here on the forum that you and the rest of Autodesk *really do* listen to your users. I thank you for it, though, because I don't think it's something that should be taken for granted. It is still somewhat unusual with large multinational companies. But this is one time where listening alone won't be good enough. 'nuf said. Now it's time for me to go bugg John….
#34322From: Tony Tanzillo [LISP TM]Feb 23, 1992 7:27 PM
Peter – I hate to tell you this, but you're going to have some dissent on your hands. I for one am not interested in any further bastardization of External references. They were designed as a means of including a canonical representation of one drawing, in another. I will instead campaign for another type of "externally-defined thing" (I can't be more specific than that, sorry), that will bring all of the functionality that you seek to have in external references, without making them so complicated that nobody but you and Mark Burns will know what to do with them. I'm not interested in making AutoCAD more complex for the sake of complexity alone. What you and Burns want from external references conflicts with their very essence (a canonical representation of an external drawing). I don't want to start a war or raging debate on this here, but I'm telling you now that I will veheminently oppose any futher hack jobs on this feature, in favor of a more rational alternative. -TonyT.
#34342From: Peter K. SheerinFeb 23, 1992 9:02 PM
Well, I'm not expecting *everyone* to be on my side, so I don't mind dissent too much. I am glad that you see the need for "some sort of thing that behaves like that", but I question (just playing the devil's advocate) whether having yet a third type of "block" wouldn't be more confusing than simply extending VISRETAIN to keep the color changes of the layer settings. I can live without the linetypes in R12, but I really think that this ability needs to be in R12, whether it's part of xref's, or some other type of external thingie. As for the request interfeering with a canonical representation of one drawing, it seems to me that meerly changing the color of a layer (to change their entities appearance from solid to screened, for instance), is a *lot* less damaging to that cannonical representation than the *current* provision of COMPLETELY HIDING LAYERS from an xref is. Or is that precicely what you mean when you say "further bastardization…"? Yes, I've heard of the original implementation's goal of simply being an analogy for the pin-bar method of combining files at plot time, but forget about the *intended* design; what do most of the people who are, or would use xref's, want/need *now*? I believe strongly that more people would side with my version than your version. Carefull now, I'm not saying that yours is wrong. I do indeed like it. I'd love to have both, but right now, If I have to choose between them, I want VISRETAIN extended. Yes, I think we need another type of xternal file referencing, but I'd prefer it to be developed in a longer time frame than what a release 12 feature could offer. If it was said many months ago that the feature set of R12 was frozen, surely your wish won't happen in R12, eh? [More]
#34343From: Peter K. SheerinFeb 23, 1992 9:02 PM
[Continued] (Pardon me, people, and Tony, if this sounds like a flame. It's not; I just feel *very* strongly about this type of control showing up in R12.) I don't think that the simple change to color settings would be at all difficult for the existing users. How many people do you see on the forum complaining "hey, why can someone turn off layers from a drawing of mine they've xrefed!?". (0) How many times do we see lurkers complaining "why do my layer property changes to xref'd layers dissappear when I save the drawing?" (more than I can count). I do agree with your opinion that there is a need for xref's of the sort you wish for, but what do we do: take visretain away completely, and transfer that functionality (and more) to your wish? Why not continue to extend Xref's, and make the new "external thingie" a *pure* canonical representation of an external file? Lastly, we *are* going to see more types of blocks/xrefs in the future; one of my earlier wishes hit about 4 different enhancements on the nail, and they were already on the wishlist. You say such changes will make their use more complicated? True, somewhat, but there are people that desire that kind of flexability/power. Things like blocks that have a scale factor relative to whatever size the drawing is plotted at, a way to xref only portions of external files (for puposes of dealing with *huge* external files, much in the same way GEO/SQL works), or for intimately twiddling with the appearance and/or visibility of individual nested entities of external files. I don't want all of this to appear as soon as R12, but I *do* think it will come, and will be welcomed. If it is possible for your proposed "external thingy" to appear in R12 with controll over color of external layers, and keep the current xref scheme, than I *fully* support your wish; I think it's a very good concept, but I don't want to have to put off a fix to VISRETAIN to R13 to accomplish it!!!!!
#34346From: Tony Tanzillo [LISP TM]Feb 23, 1992 9:32 PM
Peter – "A third type of block"? Well, that's what they'll view it as, if you choose to name such a feature that way, but that's not necessarily the way it would/could/should work. It could, for example, be called "backdrop", or "background", or what have you, which helps to make the distinction between it and the other types of complex entities. I am also not questioning your need for the functionality that you would like XREF's to provide, I am just saying that XREF's are not the preferred vehicle to provide that functionality. XREFS are externally defined things that can't reference local settings. The type of beast that I'd prefer to have for this type of externally-defined geometry that can create and reference objects in the target drawing, is preciesely what everyone seems to be trying to use the XREF for, and I maintain that it wasn't designed with that use in mind, and it should not be hacked to death in order to achieve that goal. I don't know much about what is going to be in R12 and what isn't, so I can't comment on that aspect of the subject. The real solution to most of these problems will not be realized in R12, and that has more to do with some fundamental limitations of the current database architecture that we are hoping R13 will eliminate. The real solution to this and other problems you people keep hemming and hawing about<g>, is a database architecture whose scope extends beyond both a physical and logical "drawing" (e.g, it could encompass an entire project). But you're not going to see anything like this for some time. -TonyT.