Topic: Civil 3D Templates | Registry Applications

[BlackBox]

I've always generally had some means by which to removed regapps, mostly via a simple LISP call to the -PURGE Command.

In any event, I'm noticing now that some of the regapps being removed are "AeccUiQTOPayItemSpecBookVersionFloridaDOT" and "AeccUiQTOTransportDesignerFileFloridaDOT". These regapps are being removed not only from drawings based on our custom template, but even the OOTB templates.

Now, I am one of the Beta testers for the Florida DOT (FDOT)'s Civil 3D State Kit, but they upgraded that from Civil 3D 2011 to 2012 +/- a year ago... Which is long before I setup this template for 2011 (our daily production platform).

Interestingly, I can purge these regapps (FDOT included), save, and close an empty drawing, yet upon reopening said drawing they've been added again.

One of my biggest gripes is that the FDOT is constantly violating what I consider to be common sense, in that they alter files, settings, etc. that non-FDOT profiles use. We work for more than one client, and they need to keep their plug-in separate from the core platform resources... Something that they seem to not understand, or don't care for.

In any event, can anyone else confirm this finding of FDOT regapps, or is it just me? If just me, then how do I diagnose where the regapps are coming from as I use _no_ FDOT software, resources, styles, fonts, etc. in Civil 3D 2011?

TIA

[Cathy]

I'm guessing that it is not coming from the drawing, but from Autocad.  When you start Autocad and see the whole list of things like:
Loading AEC Base...
Loading AEC Base Extended...
Loading AEC Base UI...
Loading AEC Project Base...
Loading AEC Schedule Data...
Loading AEC Project UI...
Loading AEC Base GUI...
Loading AEC Utilities...
Loading AEC Layer Manager...

Do you see anything that says FDOT?

If you open a purged drawing on a workstation that does not have FDOT carp on it, I'm guessing it will remain clean.   

[BlackBox]

Just confirmed it with a user that does not have the FDOT carp on it... Using Civil 3D 2012 (mind you I first noticed this with Civil 3D 2011), the same regapps exist in OOTB templates, and custom templates alike.

[mjfarrell]

suggest you investigate any code set styles, verify that there is none that use the FDOT pay items

[BlackBox]

suggest you investigate any code set styles, verify that there is none that use the FDOT pay items

Are you saying that you can purge all regapps from your OOTB templates and this does not appear?

In any event, that's sort of the point... We haven't set any of that up for either Civil 3D 2011, nor 2012 (see image below).

Going a step further, now that I am in a utility-based group, we don't use Corridors, Assemblies, or Sub-Assemblies for any of our work. The survey that comes in is usually either ASCII, or a Map 3D Drawing that contains Eagle Point 'points' that we import as COGO Points from which to build our existing surface, etc..

I am the only user here with the FDOT Civil 3D 2012 State Kit installed (as I transferred from a Transportation group). I went to another user here and asked that they perform a simple:

Code - Auto/Visual Lisp: [Select]

1. (command "._-purge" "r' "*" "n")
2.  

... And sure enough it's there for them as well using OOTB templates. We tried acad.dwt and acad3d.dwt if memory serves.

That said, I am unable to reproduce this when using Civil 3D as AutoCAD, which begs the question, what could OOTB Civil 3D Imperial be loading that would add the FDOT regapps? I viewed these regapp table records in MdgDbg but cannot determine where they came from.

[BlackBox]

As this is still bothering me, I've asked a coworker at the other end of the State to test for these registry applications.

We confirmed that this user does _not_ have any FDOT State Kit software installed (Civil 3D or Microstation), then proceeded to test their custom drawing template, and one of the OOTB templates. Both displayed these FloridaDOT regapps.

We proceeded to perform this same test using both Civil 3D as AutoCAD, and Map 3D... Both of which do _not_ contain these regapps.

This would suggest to me that something that has been embedded within one of the OEM Civil 3D .NET / ARX assemblies is the offending culprit, which logically means that those of you that are using Civil 3D 2011, or 2012 (and presumably 2013 but I do not have to test), also are infected... for the lack of a more sufficient word.

Would anyone else be kind enough to please confirm that these *FloridaDOT regapps are incorporated into their Civil 3D drawings?

I am trying to determine who to direct my frustration... Florida DOT, or Autodesk.

[Wedding]

[Pure speculation here, I have NOT tested nor confirmed this with the development team.]

I think you are seeing some of the code remnants of the QTO modules. You'll notice that one of the Pay Item list formats is from FDOT. I'd bet there's a RegApp associated with that code. It's been in there a number of years. You're welcome to unload it, but as you noticed, it will be reloaded as soon as you open C3D, due to the QTO hooks calling it.

Again, that's my guess, hope this helps explain the existence.

[BlackBox]

[Pure speculation here, I have NOT tested nor confirmed this with the development team.]

I think you are seeing some of the code remnants of the QTO modules. You'll notice that one of the Pay Item list formats is from FDOT. I'd bet there's a RegApp associated with that code. It's been in there a number of years. You're welcome to unload it, but as you noticed, it will be reloaded as soon as you open C3D, due to the QTO hooks calling it.

Again, that's my guess, hope this helps explain the existence.

I appreciate the educated guess (is this, James ?). 

Following my recent testing, I believe this to be something that is added by Civil 3D modules... I communicated that speculation on my part in an email to Jay (Front-line AutoCAD MEP) whom I've been working with recently on a small handful topics regarding Civil 3D & AMEP. In my email to Jay, I pointed out that my thoughts on this particular topic may be better directed toward his Civil 3D counterpart, but since I have recently worked with him, I felt confident that he would get that information to the correct individual(s).

[Wedding]

Yes, that's me. How many Civil 3D guys named Wedding could there be? 

Anyway, Jay's on my team, I'll talk to him, but since it's linked to the QTO components, I don't know that we'll change anything here. In the interim, at least you know it's not coming from a ghost.

[mjfarrell]

suggest you investigate any code set styles, verify that there is none that use the FDOT pay items

Are you saying that you can purge all regapps from your OOTB templates and this does not appear?

In any event, that's sort of the point... We haven't set any of that up for either Civil 3D 2011, nor 2012 (see image below).

Going a step further, now that I am in a utility-based group, we don't use Corridors, Assemblies, or Sub-Assemblies for any of our work. The survey that comes in is usually either ASCII, or a Map 3D Drawing that contains Eagle Point 'points' that we import as COGO Points from which to build our existing surface, etc..

I am the only user here with the FDOT Civil 3D 2012 State Kit installed (as I transferred from a Transportation group). I went to another user here and asked that they perform a simple:

Code - Auto/Visual Lisp: [Select]

1. (command "._-purge" "r' "*" "n")
2.  

... And sure enough it's there for them as well using OOTB templates. We tried acad.dwt and acad3d.dwt if memory serves.

That said, I am unable to reproduce this when using Civil 3D as AutoCAD, which begs the question, what could OOTB Civil 3D Imperial be loading that would add the FDOT regapps? I viewed these regapp table records in MdgDbg but cannot determine where they came from.

what I'm saying is that the code sets have data in them linked to the QTO, as somewhat reinforced by WEDDINGS speculation to same

[BlackBox]

Yes, that's me. How many Civil 3D guys named Wedding could there be? 

Pleasure meeting you, James.

Anyway, Jay's on my team, I'll talk to him, but since it's linked to the QTO components, I don't know that we'll change anything here. In the interim, at least you know it's not coming from a ghost.

what I'm saying is that the code sets have data in them linked to the QTO, as somewhat reinforced by WEDDINGS speculation to same

No worries. Sorry if I didn't understand you fully the first time, Michael... In any event, I am less concerned now knowing that this is being intentionally added to the database by OEM Civil 3D components.