Topic: adding a new document without activating it

[GUIDO ROOMS]

is it possible to add a new document without actually activating it?
i know i can return to the active document after adding a new one but i want to avoid that.
it's annoying for  some users. they hate things flickering on and off on their screens.
some might even throw a conniption fit.
i want to avoid that.

[BlackBox]

Not that I am aware of. 

[GUIDO ROOMS]

thanks.
just thought i'd overlooked something.

[nekitip]

You can "add" document as a side database. You'll be able to access objects, and users will not see "new document opened".
Not sure, but is this what you were looking for?

[GUIDO ROOMS]

no, I meant really opening a document, but not switching to it immediately.
i knew about opening a database, but that's not what i meant.
thanks for the reply anyway.

[Alexander Rivilis]

I've did not tried that but what about to set Application.DocumentManager.DocumentActivationEnabled to false before opening new document?

[GUIDO ROOMS]

Alexander,

thanks fot the reply.
but the piece of code below just throws en exception (file error).

Code: [Select]

Application.DocumentManager.DocumentActivationEnabled = False
Dim NewDrawing As Document = DocumentCollectionExtension.Add(Application.DocumentManager, "acadiso.dwt")
Application.DocumentManager.DocumentActivationEnabled = True


[BlackBox]

1+

Thanks, Alexander!

Alexander,

thanks fot the reply.
but the piece of code below just throws en exception (file error).

Code: [Select]

Application.DocumentManager.DocumentActivationEnabled = False
Dim NewDrawing As Document = DocumentCollectionExtension.Add(Application.DocumentManager, "acadiso.dwt")
Application.DocumentManager.DocumentActivationEnabled = True


You didn't include your complete code, so impossible to know for sure, but it seems as though you've neglected to implement the required Module and Imports statements for VB (C# can call Extension Methods directly).

See Gile's post here for more information:

http://forums.autodesk.com/t5/net/vb-net-2014-document-object-issues/td-p/4619699

Cheers

[GUIDO ROOMS]

In order to be crystal clear, I've attached the complete class below, including the exception it throws (as comment).

Some remarks:

(1) What Giles writes is simply not true: in Visual Basic Net you don't have to define your commands in a module. You may define them in a class. As I always do. I never use modules. Modules are classes with all members shared. Modules are classes in disguise.

(2) I don't have to import 'DocumentCollectionExtension', since it's a class, not a namespace. Although in Visual Basic you could use the Imports statement to import a class. (I sometimes do that with 'System.Math', for example.)

(3) I've forgotten to mention that the code is being tested under autocad 2015.

Code - vb.net: [Select]

1. Imports Autodesk.AutoCAD.ApplicationServices
2. Imports Autodesk.AutoCAD.Runtime
3.  
4. Public Class Docs
5.  
6.     <CommandMethod("NEWDOCNOTACTIVE")>
7.     Public Shared Sub NewDocNotActive()
8.         Application.DocumentManager.DocumentActivationEnabled = False
9.         Dim NewDrawing As Document = DocumentCollectionExtension.Add(Application.DocumentManager, "acadiso.dwt")
10.         Application.DocumentManager.DocumentActivationEnabled = True
11.     End Sub
12.  
13.     'The above throws:
14.     'An exception of type 'System.Runtime.InteropServices.COMException' occurred in acmgd.dll but was not handled in user code
15.     'Additional information: File error.
16.  
17. End Class
18.  

But again, thank you Alexander.
Cheers!

[gile]

Some (off topic) remarks:

(1) What Giles writes is simply not true: in Visual Basic Net you don't have to define your commands in a module. You may define them in a class. As I always do. I never use modules. Modules are classes with all members shared. Modules are classes in disguise.

If you had read more carefully the message linked by BlackBox, you would have seen that I was not speaking about commands (<CommandMethod()> attribute) but about extension methods (<Extension()> attribute).
With C#, extensions methods have to be defined within a static class, with VB, they have to be defined within a module.
The Add() method is an extension method defined in the DocumentCollectionExtension static class (C#) or module (VB). It extends the DocumentCollection type, and so can be called as an instance method for this type.

(2) I don't have to import 'DocumentCollectionExtension', since it's a class, not a namespace. Although in Visual Basic you could use the Imports statement to import a class. (I sometimes do that with 'System.Math', for example.)

I don't know much about VB (I farly prefer C# or F#), but I am certain of what I say about the need to import a VB module in which are defined extension methods so you can call them as instance methods.
There is a difference between a C# static class and a VB module: with VB, a module have to be explicitly imported when used out of its scope (this is not needed with C#).

IOW, this:

Code - vb.net: [Select]

1. Imports Autodesk.AutoCAD.ApplicationServices
2. Imports Autodesk.AutoCAD.Runtime
3.     ' [...]
4.             DocumentCollectionExtension.Add(Application.DocumentManager, "acad.dwt")
5.     ' [...]

is equivalent to this:

Code - vb.net: [Select]

1. Imports Autodesk.AutoCAD.ApplicationServices
2. Imports Autodesk.AutoCAD.Runtime
3. Imports Autodesk.AutoCAD.ApplicationServices.DocumentCollectionExtension
4.     ' [...]
5.             Application.DocumentManager.Add("acad.dwt")
6.     ' [...]

[Jeff H]

LINQ was a main motivator for extension methods but one of the main reasons was to avoid the "utility" or "helper" class code and make it more natural.

Code - Visual Basic: [Select]

1.             Dim numbers As New List(Of Integer)
2.             numbers.Add(1)
3.             numbers.Add(2)
4.             numbers.Add(3)
5.  
6.             If numbers.Any() Then
7.  
8.             End If
9.  

vs

Code - Visual Basic: [Select]

1.             If System.Linq.Enumerable.Any(numbers) Then
2.  
3.             End If
4.  

They are just syntactic sugar but might as well take advantage of it to make code cleaner.

If the assemblies were built correctly you could avoid that and there is way to make sure it works in VB as C#.
I think it has something to do with how VB plays tricks and make members in Modules global to entire project vs referencing it as an assembly.
Where in a project you do not have to use its Type to access a function or variable
like with shared or static.

Code - Visual Basic: [Select]

1. Module Module1
2.     Public Sub Fart()
3.     End Sub
4. End Module
5.  
6. Public Class Class1
7.     Public Sub poo()
8.         Fart() <------------
9.     End Sub
10. End Class
11.  

Extension Methods have to be in Modules but if you place the Modules inside a NameSpace then you can just import the NameSpace

Code - Visual Basic: [Select]

1. Namespace Extension <-----------
2.     Module Module1
3.         Public Sub Fart()
4.         End Sub
5.     End Module
6. End Namespace
7.  
8. Imports ConsoleApplication6.Extension  <-----------
9. Public Class Class1
10.     Public Sub poo()
11.         Fart()
12.     End Sub
13. End Class
14.  

For future reference

(1) What Giles writes is simply not true:

Everything gile writes is true.

[Kerry]

< .. >
For future reference

(1) What Giles writes is simply not true:

Everything gile writes is true.

That axiom is indisputable !

[gile]

< .. >
For future reference

(1) What Giles writes is simply not true:

Everything gile writes is true.

That axiom is indisputable !

This is not true.

Like many others here, I just try not to write about things I'm not sure or I have not checked.

[Jeff H]

< .. >
For future reference

(1) What Giles writes is simply not true:

Everything gile writes is true.

That axiom is indisputable !

This is not true.

Like many others here, I just try not to write about things I'm not sure or I have not checked.

That comment was meant as a thanks for all the great information you have shared

[Kerry]

... and my comment was in support of Jeff ... because you DO 'not write about things you're not sure of or have not checked.'

that is what makes almost everything you write true.