Topic: Cannot set MdiActiveDocument

[Bryco]

Nextfiberworld = 1 may not be a good solution if it ruins a users ribbon.

I tried Will Hatches dll, the debug   didn't do so good on  Nextfiberworld = 0, but the release did ok
So it may pay to make sure you use release.

Perhaps someone else could  test that too

[WILL HATCH]

Changed Fiberworld = 1, the active drawing is now shown correctly.

Can you confirm you restarted autocad after making the change?

Yes, I always restart after changing this.

Thanks, just trying to wrap my little brain around this. Can anybody else on C3D confirm this behaviour?  If I get time to install C3D tomorrow and play I will

Nextfiberworld = 1 may not be a good solution if it ruins a users ribbon.

I tried Will Hatches dll, the debug   didn't do so good on  Nextfiberworld = 0, but the release did ok
So it may pay to make sure you use release.

Perhaps someone else could  test that too

You confuse me with this statement... I thought that NEXTFIBERWORLD=1 is the default behavior, I've also never noticed a difference between release and debug builds aside from compiler optimizations.

Why Autodesk... WHY!?!?!  :realmad:

[Jeff H]

AutoCAD uses or will be "used" fibers for swapping call stacks within a thread. Microsoft has deprecated fibers and so is AutoCAD or until fiber8 comes out with VBA8
"Application Context" is a separate fiber which is common between documents, and used for switching document.
 
When NEXTFIBERWORLD = 0 and AutoCAD is restarted and "fiberless" instead of switching call stacks it has to "return" from the document, before executing in "Applicaton context"
In "fiberless" mode the actual activation is delayed or deferred and any prompt will never leave document context.
 
With Fiberless Open, Add. etc... or anything that uses AcApDocManager(DocumentManager) is effected.
 
With NEXTFIBERWORLD = 0 and restarted("fiberless")then a function started in a document must return before it is able to switch.
Also anything that uses acedcmd or acedcommand will fail, when AutoCAD is "fiberless".
 
So if you set AutoCAD to "fiberless" then code scripted via pinvoking acedcmd should fail.
 
Mac has no concept of fibers and look at AutoCAD for MAC documentation for acedcmdS or acedcmdP or acedcmdN or acedcmdC,  acedcmd followed by two different letters.
 
On the upside acedCommand relies on fibers and .NET does not support fibers and the main reason why never exposed so in when fiberless switch is made they should expose it.

[Jeff H]

... You two (Jeff & Jeff respectively  ), are endless sources of API knowledge; it's pretty schnazzy. 

That just comes from spending the time of opening Reflector or ILSPY and opening every assembley in AutoCAD install folder then remove all the ones that are red and seeing how they handle it themselves for parts of the software that exposed through .NET.
Just skimmed through quickly and most are crap but highlighted ones are ones you actually use in product.(I think)
 
 
 

[Kean]

Hello everyone,

Kerry pinged me to take a look at this thread. I only skimmed it, so please tell me if it seems obvious I've missed something important.

I went ahead and tried the code with AutoCAD 2014, Windows 7 64-bit.

It works for me with fibers turned on (FIBERWORLD == 1). It fails with fibers turned off (FIBERWORLD == 0) with the eNotApplicable error on any use of docBlock.Editor, but I believe that’s due to 2014’s fiberless implementation being incomplete.

I also tested the code on an internal build with fibers off and it seems to work properly. So I wouldn’t be worried about getting it working in AutoCAD 2014 with fibers off, for now (using fibers is still the supported mode of operation for 2014, I only ever turn them off when needing to debug specific pieces of code).

Hopefully this helps and I didn't miss the point.

[Jeff_M]

Thanks for chiming in on this, Kean.

One other thing to note and be aware of. When Fiberworld=0, and the Activedocument is not the document you think it should be, the WorkingDatabase WILL be the new database:

[Kean]

Interesting. Based on your comment I just tried setting HostApplicationServices.WorkingDatabase to docBlock.Database, to see whether that stopped the exception when running fiberless, but it didn't change anything.

The problem is no doubt deeper, and unlikely to be possible to work around (other than setting NEXTFIBERWORLD to 1 and restarting, that is ).

[Jeff H]

Hi Kean,
 
Will Hatch posted a link to one of your blog entries in a earlier post
http://through-the-interface.typepad.com/through_the_interface/2011/09/no-source-available-when-debugging-an-autocad-plug-in.html
 
A snippet from the very bottom.

For ADN members interested in a bit more background on this topic, see this DevNote and an article in this newsletter edition.

The link from this newsletter edition has some information and contains a link to a white paper with more information.
 
It would be very useful for all to have access to the information. 
 
With ADN OPEN you think they could publish that at ADNBlog or made publicly somewhere?
 
 
 

[Kean]

I would think so. I'll ping ADN and ask them to do so.

[Kerry]

Thanks Kean.
Regards,

[Bryco]

Thanks Kean as well.

I found a few autocad commands going crazy while I had fiber =0.
From the docs it makes sense xopen wouldn't work  but not being able to put an object on a turned off layer w/ the layer manager and being able to do it with the properties window makes me wonder how the Layer Control toolbar is thread/ fiber related

[Kean]

There're a whole load of issues that crop up in 2014 with fibers off, some of which indeed don't seem to relate to multi-document operations.

BTW - it seems the DevNote I linked to has made it onto the AutoCAD DevBlog:

http://adndevblog.typepad.com/autocad/2012/12/breakpoints-in-custom-form-not-hit-when-debugging-net-addin-for-autocad-2012-from-visual-studio-2010.html

Unfortunately the whitepaper hasn't as it's quite out-of-date: much of the information contained is no longer accurate. The ADN team will definitely be publishing more on the topic in due course (as will I).

[hperison]

This is an interesting and very confusing topic especially when I see the phrase used in one of Kean's blogs that states: "still uses fibers".   As I keep reading about this subject, it seems that AutoCad is eventually going to be fiberless or am I mistaken.

Anyways, it is interesting that I have an application that will work with the opposite results.  It appears that all were having issues during runtime when NEXTFIBERWORLD = 0 and did not experience any successes until they set the value to 1.

I am the opposite as I can run seamlessly during the debug phase with NEXTFIBERWORLD = 1 but will experience a Fatal Error during release mode.    This will always happen when I rerun the application a couple of times in a row without engaging a new drawing session. 

FYI, my application is creating numerous drawings from a master document and requires switching back to the master/parent document before creating another.  Once the new drawing file has been created, the file is then saved and subsequently closed/discarded.  The application will then return to the parent to create another.   

However, when I set NEXTFIBERWORLD to 0, I can rerun my application in release mode numerous times with complete success and no Fatal Errors.

Is there any documentation on NEXTFIBERWORLD?   
Isn't NEXTFIBERWORLD = 1 the AutoCAD default?

It probably would be better if I knew which commands or functions didn't like NEXTFIBREWORLD = 1 and then I could adjust accordingly and not have to set my AutoCAD to use a value of 0.  Currently, I have to reset NEXTFIBERWORLD back to 1, when I am done, in order to prevent other issues.  A real 'pain in the a$$'

[Kean]

Microsoft deprecated their fiber technology some years ago. Eventually Visual Studio stopped being able to debug fibers properly, hence the need to turn them off to use VS2010 to debug event callbacks, jigs, etc., in AutoCAD.

It's actually very natural that your code works well with fibers on (FIBERWORLD == 1) when not being run from the VS debugger. AutoCAD's fiberless implementation (FIBERWORLD == 0) is still incomplete in AutoCAD 2014: we recommend turning fibers off if you need to to debug, but you should turn them right back on afterwards. AutoCAD for Mac doesn't have the luxury of being able to use fibers, so we're most of the way there, implementation-wise. But there are still some quirks we need to iron out (and we're working hard on them).

I get strange behaviour after opening drawings in AutoCAD 2014 with fibers off, for instance: the input-throat just starts swallowing keyboard input until I hit Ctrl-C a few times (and then cancel the COPYCLIP command). Then things seem to work OK, but still.

To be clear: I've mentioned FIBERWORLD above, as that's the read-only sysvar that tells you whether fibers are on (1) or off (0) for the active session. NEXTFIBERWORLD sets whether fibers will be on (1) or off (0) for the next session, as you can't switch that on-the-fly for the current session.

The default in AutoCAD 2014 is currently for fibers to be on, but the writing is very clearly on the wall (and has been for many years, in fairness to Microsoft). Fibers are, at some point in the future, going away completely.

Kean

[hperison]

Thank you for the clarification.  You write much better than me.        My apologies to all for continuing to take this topic off course.

Kean, To clear up a misconception. I previously wrote that my program did the following ( a synopsis):

For NEXTFIBERWORLD ==1    (AutoCAD 2010/2014 build with VS2010 or VS2012 [for PC])

Release Mode:     produces a FATAL ERROR      e0434352h    @ fda2a49dh     (Fatal Error occurs if the application is executed more than once, back to back.)
Debug Mode:       works very well    (this is where I did all of my development)


For NEXTFIBERWORLD ==0     (AutoCAD 2010/2014 build with VS2010 or VS2012 [for PC])

Release Mode:     executes nicely   (I can execute the application numerous times back to back without error)
Debug Mode:       works very well

       (After the program is complete, subsequent AutoCAD functions do not work very well.  Many times I receive the "spinning wheel of death")

So this just appears to be strange because for everything that I read about NEXTFIBERWORLD == 0 my program shouldn't work very well at all except during debug.   Release should have issues where there are none.

I know for a definite fact that I am not that good of a programmer.