Known Bug List

[matthew_taylor]

I'm vetting Revit 2018 right now.

So far, I've found a bug with the UI (User Interface), and three with the API (Application Programming Interface).

It would be great if Autodesk had a public list of bugs! (Don't show security related bugs...)

That way we can:

1. Not waste time reporting bugs again.
2. Make an educated decision about using the latest version.
3. Be aware of limitations.
4. Have an idea when a bug will be fixed.
5. Minimise testing time.

This is a no-brainer. It helps everyone.

Thanks for reading. (And your up-vote!)

p.s. The bugs I have found with Revit 2018 so far (all have been reported):

• UI: Click editing of Multiline Text parameters doesn't work. (Due to be fixed in version 2018.1) (Workaround is to edit in Properties palette.)
• API: Starting a Windows Explorer process when batch creating DWF. (Causes 'save recovery file?' crash.)
• API: Starting a Windows Explorer process when batch creating DWG. (Causes 'save recovery file?' crash.)
• API: Unknown bug when batch creating individual DWG files. (Causes 'save recovery file?' crash.)
• API: Not actually a bug, but undocumented new behaviour...Undocumented new exception when using PromptForNewFamilyInstance: See here.

[c_hanschen]

It is part of a commercial tool for Itannex BV Almelo, The Netherlands.

The tool allows you to Print multiple sheets as single sheets, multiple sheets as a book, export DWG, DXF and IFC on one Run.

The user can choose it own printer (combobox), hardware printer or virtual printer, as well as settings for quality, filenames, etc, etc.

I use BioPDF, it is a free PDF printer, this PDF printer is adjustable so it does not ask for (conformation of) every filename.

The trouble in Revit 2017 only appears when printing AND exporting from behind a modal form in one Run.

The code loops over all sheets to print, then loops over all sheets to export to DWG, then loops over alle sheets to export to DXF, and so on.

I now removed the code (with the loops and API calls Printout and Export) to the ExternalCommand. (code no longer running from behind the dialog)

That solved the problem is Revit 2017 (stil a bug?) but still issues in Revit 2018.

I'm writing this Addins on a laptop, running on Windows 10 Home Edition.

Chris Hanschen

LKSVDD architecten Enschede

The Netherlands

[matthew_taylor]

Hi @c_hanschen,

Thanks for the info.

With regards to BioPDF, have you checked out the OnAfterPrint event? (Had a quick look on the website.)

When I did my PDF export, I had to do a 'wait' loop until such an event told the loop to stop. Otherwise, they were trying to write to the same file. That sounds like the 'Attempted to read or write protected memory' issue you mentioned.

Do you rollback all of your transactions? I have found issues (especially in 2018) where doing this makes a difference. This should also rule out any read-write issues with writing to your Revit model.

I've also found an issue getting the doc.PrintManager object. This issue occurs when no Windows printer is set to 'default' (in Control Panel\Hardware and Sound\Devices and Printers). I find Revit a bit touchy with printing. The .SubmitPrint sub can set global settings which I find annoying.

Anyways, maybe one of these items spurs an idea.

[c_hanschen]

The most errors occurred when exporting DWG and/or DXF too quick after the prints.

The prints alone are not the problem.

Only a lot of DWG's was not a problem, so that may be why you did not experience this issues, it's the combination that makes Revit Crash.

I send a different filename to every Printout command, so the code (or BioPDF code) is not writing the same file twice.

(this way no need to rename post printing)

The file's already existing in the output folder (with these filenames) are even deleted before proceeding, so that's not the problem also.

(Revit API Printout command stops when filename already exists, even when the PDF printer is set to 'overwrite')

I have even tried to wait in the loop for the File (Printout en DWG) to become ready, than wait an extra second and then continue loop.

That was not the solution at that time, I had to close the modal dialog in order to end problems in Revit 2017.

And yes, I rollback my transaction after printing.

The exports DWG and DXF do not need a transaction, so the transaction of printing is already rolled-back before exporting.

Can that be a problem? 

I even tried (at some moment of desperation) to make a transaction for the exports, but that was not the solution at that time.

I will send my code and project to @jeremytammik, but this will be later on this day (evening)

Chris Hanschen

LKSVDD Architecten Enschede

The Netherlands

[c_hanschen]

I have tried to make a 'simple crash test code' for reproduction of the problem.

I first builded a code that exports all 89 sheets of a project, not just once, but 10 times in a row.
(With different filename for each loop)

The result: 890 Sheets, no problem, can't get Revit 2018 to crash with only exporting DWG.

Than I builded a test code that prints all 89 sheets to the current printer.
(I stripped my code from UI and all the customize-able user setting, just printout every sheet in seperate printout command)
This code is followed by exporting all 89 sheets to DWG and than all 89 sheets to DXF.
I runned it 3 times, no crash.

I am building this tool for Revit 2016,2017 and 2018.
Can it be a problem if the DLL was compiled with API references of version 2016 and than run in 2018?
Visual studio does not report any warnings or errors when switching between Revit API 2016,2017,2018.
(Because the commandline parameters have not changed for printout and export)
Maybe that was the case in my latest test with the mentioned error.
In that case it is still strange that the small project did not crash and the medium project crashed in the second run.

to be continued....

Thanks anyway for all the support so far.....

Chris Hanschen
LKSVDD architecten
The Netherlands.

[c_hanschen]

Hello,

here's an update:

Revit 2017

Because of the answers in this topic :

I rewrote the way all the tasks (printing & exporting) where handled

Like @matthew_taylor says: "The code runs the dialog, not the dialog running the code"

Now my Dialog (with a lot of user selections for views and sheets and their settings) is closed, all data is collected in variables, than the external command runs the API calls for printing and exporting. No more references to 'MyDialog' when processing prints and exports.

This worked great for me in Revit 2017 and solved all my problems, i think these problems had to do with 'printing and exporting from a behind model form'. 

So I think that Revit 2017 also had issues like mentioned here .

Autodesk should be able to confirm or deny that.

Does not really matter for me, my Revit 2017 problems where solved anyway.

Now back to Revit 2018:

I recompiled the working code for Revit 2017 with reference to Api dll's version 2018.

I opened my testproject (medium size project) and started a test with printing and exporting.

I ran this test over an over again, succeeded every time!

After the 5th run, the following error appeared (like mentioned before)

"Attempted to read or write protected memory. this is often an indication that other memory is corrupt"

The strange this is, the code was completed successfully, even the messagebox reporting "all succeeded" was behind the errormessage.

see Attachments of this post for screendump.

So actually, all prints and exports where completed just fine...!! 

The messagebox (from my code) is modal, so my code stopped here.

Is it again a problem with a modal form? (messagebox this time while Revit was finishing up in the background?)

I can try testing it over and over again without showing a messagebox at the end.

After clicking 'OK' on the 'error messagebox' Revit Crashed, it did not return to the other messagebox.

I googled the error mentioned above, I found this result:

https://stackoverflow.com/

here the problem is subscribed to many factors, like:

- built for platform 

- virus scanner

- .NET version

- and so on.... 

My Visual studio project is targeting .Net Framework 4.5.2.

I will keep on testing, give a update when I found something.

Any help will be appreciated.

Chris Hanschen

LKSVDD architecten Enschede

The Netherlands

+xxx-xxxxxxxx

[matthew_taylor]

Hi @c_hanschen,

Good update.

I wonder whether you have followed the stack trace for your exception, as it appears you are actually catching it in the (LKSVDD branded) dialog?

I use something like this:

Public Shared Function ExceptionDescription(ByVal ex As Exception) As String
   Return String.Format( _
      "EXCEPTION TYPE: {3}{1}SOURCE: {4}{1}MESSAGE: {0}{1}STACK TRACE: {2}{1}CALLING METHOD: {5}", _
      ex.Message, vbCrLf, ex.StackTrace, ex.GetType.ToString, ex.Source, ex.TargetSite.Name)
End Function

That normally provides me with enough information to see what/where the issue is. Especially useful for oddly timed things like this.

Hang on. You had two dialogs show at once, on top of each other? If they're both modal, this shouldn't be possible (in this context).

Temporarily change them both to plain MsgBox(<your alert>) statements.

Do you use any events? DialogBoxShowing or similar?

[c_hanschen]

@matthew_taylor,

My code only 'asked for' the messagebox with completion info of the actions, and yes, it's modal.

The end of the code is like this: (after printing and exporting, the 'try' line is on the beginning of all the actions)

If MyMessageBoxMessage = "" Then
MsgBox("Nothing exported or printed..!!")
Else
MsgBox(MyMessageBoxMessage, MsgBoxStyle.Information)
End If

Catch ex As Exception
MsgBox(ex.Message)
End Try

Return Autodesk.Revit.UI.Result.Succeeded

I think the error message is from .Net

While my Messagebox is shown (2nd line in code above), some bad thing happens, the entire addin is interrupted, causing the second message to appear.

I did not check if both where modal, but I think so, the first one is and the other one was above that, so is has to be.

It should not be possible to have 2 messageboxes at the same time, so the can't me both from the code above.

Because of the Revit Crash after closing down the messagebox with the error, tell's me that something in Revit caused the Addin the crash, I still think that it has something to do with a threading issue, Revit is finishing up in background processes while there is a model form (the messagebox)

that also explains why there are 2 messageboxes present at the same time. one has to be from higher level.

quote:

"as it appears you are actually catching it in the (LKSVDD branded) dialog?"

The Dialog is completely closed, ExternalCommand is running.

The caption of both messageboxes is the name of the project, as it would be from ExternalCommand.
When it would be from the dialog, the caption of the dialog should be mentioned, right?

I will give it a number of tries without ending with a dialog box, try if I can Revit to crash also, then we can rule that out.

thanks again for your response, it's nice to have a conversation about this like that!

Chris Hanschen

LKSVDD architecten Enschede

The Netherlands

[c_hanschen]

@matthew_taylor and @jeremytammik,

NOW WE ARE GETTING SOMEWHERE..!! REPRODUCIBLE CRASH CODE COMING UP

I first tested if it got anything to do with 'revit as active application'.
I started the Addin to run the prints & exports, then activated an other application (Outlook)
The first test succeeded.
the second run failed. (same error message)
So you can't say that this is a problem, because first run succeeded.

After that, I removed the displaying of a messagebox at the end of my code, I ran it over 6 times, no crash...!!

I wrote before about my test code, but I couldn't get revit to crash with it. (ran it over 10 times)
The test code was not displaying a messagebox at the end, just printing and exporting sheets.
So I have changed my 'Crash Test Code', ending with a messagebox.
And 'Yes' (never was happy with a crash before) Revit did Crash first run...!!

So now I think to know for certain, Revit Crashes when there is a model form (by example a messagebox) and Revit has got to finish business in background.
There was more info on the crash, see attachment.

@jeremytammik
It is a simple 'Crash test code', just printing all sheets, then exporting all sheets to DWG, then exporting all sheets to DXF, than show a messagebox and wait for Revit to crash.

The same code does not crash when removing the messagebox at the end.
If it does not Crash first run, give it some tries please.
I will send the 'Crash Test Code' to you on the e-mail.

Chris Hanschen

LKSVDD architecten Enschede

The Netherlands

[matthew_taylor]

Hi Chris,

Sounds a lot like my initial issue with exporting from Revit 2018. I restructured the way my macros went (so the Windows Explorer call went after all exporting). That seemed to work nicely.

Have you tried separating your app - clinically - from a UI to a non-UI scenario? Does that solve any issues?

[Viveka_CD]

Hi @c_hanschen

Thank you for all the input.

I recommend that you make a separate post for the PDF printing issues you are facing. That way the printing issue gains more focus and fetch responses from the forum.

We can take a look at your file to troubleshoot this issue further. Let me know if you have questions sending a file to test.

Regards,

[c_hanschen]

@matthew_taylor

I completely separated my code, first show UI, close UI, get all the info from UI and store in local vars, then start prints & exports.

Even better, there are no windows explorer calls and there is no UI interface in the code that I have send to @jeremytammik

It's just printing, exporting, show a modal form after completing and revit crashes because of the modal form (messagebox)

(no modal form = no crash)

@Viveka_CD

I don't think it has to do with PDF, printing to any printer and exporting probably give the same error.

maybe printing alone or exporting alone will give the same problems. That's for Autodesk to find out 🙂

I think it is the combination.

I have send my code to test to @jeremytammik He asked for a macro, I can't provide that, I'm not familiar with writing macro. (not in Revit)

I can sent a complete Addin (.dll-file + .addin-file) instead.

@jeremytammik, is it okay to sent a dll+addin?

I'm very happy with the outcome of my tests, with thanks to Matthew and Bobby I now have a work-around.

I started with a Dialog and code running from behind the dialog. 

Moving the code from behind the dialog to the ExternalCommand solved the problems in Revit 2017.

Skipping any modal forms (even popping up a messagebox after completion) solved my crash issues in Revit 2018.

I still hope for an solution, so I can show a modal form while running.

this way I can show progress and allow the user the cancel the running code.

Chris Hanschen

LKSVDD architecten Enschede

The Netherlands 

[jeremytammik]

Dear @c_hanschen

For a reproducible test case, the next best thing after a macro is a complete Visual Studio solution including source code and add-in manifest.

http://thebuildingcoder.typepad.com/blog/about-the-author.html#1b

Please understand that the whole sample is of little use for analysis and fixing purposes if it cannot be executed and debugged step by step.

Thank you!

Cheers,

Jeremy

[c_hanschen]

@jeremytammik

I understand.

As requested, you will get 'complete Visual Studio solution including source code and add-in manifest' later these days, probably before Monday!

Cheers,

Chris Hanschen

LKSVDD architecten Enschede

The Netherlands.

[c_hanschen]

@jeremytammik,

The mail been send!

A full VS solution and a large description, with all the screen dumps of all the error's.

Many thanks for considering my request.

Chris Hanschen

LKSVDD architecten

The Netherlands

[mikako_harada]

Hi Matt, 

Sorry for being slow in response. (I'm not like Jeremy 🙂 

I just created a "floating-on-top" post to use to collect known change requests:  

https://forums.autodesk.com/t5/revit-api-forum/known-change-requests-community-tracking/td-p/7166043

I did have a discussion internally.  Internal tracking system have way too much information; internal discussion among engineers which does not make any meaning to us most of the time. some may have business case from partners and customer information.  In some cases, even one tread can be a months long discussion. I know this is way far from what you are suggesting.  But we'll start with small step that I could do at a moment.  Thanks again for the suggestion.   

[matthew_taylor]

Actually fixed in Revit 2018.1:

UI: Click editing of Multiline Text parameters doesn't work. (Due to be fixed in version 2018.1) (Workaround is to edit in Properties palette.)

[Anonymous]

Hi Matt

You haven't included this one, assuming it is a bug:

https://forums.autodesk.com/t5/revit-api-forum/linear-dimension-style-does-not-duplicate-in-2018/m-p...

Regards

Paul

[Anonymous]

@c_hanschen

If you really really want a UI showing that (in my experience) won't interfere with Revit's processing in any way I suggest creating a Form that runs its own message loop (i.e. running Application.Run) on a *separate thread* and using Invoke/BeginInvoke to interact with it from the main thread. This is how I've managed to get responsive asynchronous progress bars working in Revit during processing without affecting the main UI thread / message loop in any way...