Topic: Document dwg changes or dwg diary

[Mark]

I fishing for ideas here. I want to create some way of storing a diary of dwg changes from user input. In other words some way for one to document what one did in that particular dwg. I kinda like the XNotes thing I'm working on but that leaves out the person who doesn't have acad. I also thought about creating a main diary somewhere on the network but that might get unmanageable. Any and all ideas welcome.

Thanks

[MP]

We've done it both ways -- write out a log to the network; write a log to a dictionary in the drawing. Obviously the latter means a non CADD type cannot view the data. Both ways share common design requirements, including "what do we log?". If you log everything you will bloat, beyond comprehension, the internal or external log. You have to decide "What are the critical activities?".

For us it distilled down to the datestamp and loginname for these simple events:

(1) When a drawing was opened
(2) When a drawing was saved
(3) When a drawing was renamed
(4) When a drawing was repathed

It doesn't sound like much but it gives us the ability to trace the history of the drawing. When things go wrong you generally know when; we just look back thru the logs and go "Aha!". Dialing ... "Se7en, can you come down to my office for a second?"

Also, storing the information in a concise format will help lots too. While english like sentences make it easy to casually browse logs, it can contribute to bloat, whereas a bitcoded system for identifying activies and using the compact date format as returned by the cdate system variable can save you precious bytes. It really does add up. You can write utitlities to search the data easily enough.

You mileage may vary; hope this gives you some ideas for designing your own system. Cheers.

PS - You could use Se7en's upcoming huffman encoder to save even more bytes :)

[Mark]

Also, storing the information in a concise format will help lots too. While english like sentences make it easy to casually browse logs, it can contribute to bloat, whereas a bitcoded system for identify activies and using the compact date format as returned by the cdate system variable can save you precious bytes. It really does add up. You can write utitlities to search the data easily enough.

That's some good advise, thanks.

Just to explain a bit more, while storing the dwg activities is one issue I also need the ablility for the user to enter simple statements into the file as well. i.e. "West boundary line changed due to additional monumentation found".

What about creating a new log file per dwg in a central location. Then appending to it as needed.

[MP]

Hmmm ... my initial reaction is to suggest you separate these programming tasks, it would keep things simpler.

Regardless though, if you wish to keep the data compact, private, protected whatever you will have to provide the interface to allow adding, modifying, deleting, viewing the user entries -- that will prove to be far more ambitious than the actual logging or data storage aspect.

The programming path is always the same, What is the deliverable? What is the best path to achieve the product? What programming language(s) best suit the requirments? What is the anticipated effort to achieve the stated? Is it worth it? Loop. Subtitle "I'd spend a fair amount of time with a pencil sketching this one out before committing anything to code; then I'd do some quick (read throw away) code prototypes to prove feasibility.

FWIW ... MP

[Mark]

>FWIW ... MP
It's worth a lot, thanks.