Thank you for looking at this question.
I'm facing a strange problem while publishing BOM model b2xa source code to Decision center.
I have already a rule app project published on decision center and well tested there. For one change in BOM method, b2xa file is modified and I tried to publish it to Decision center but it could not publish.
Pop window appears and says "Problem occurred in publishing the BOM" error details says Null pointer exception. No trace in log files. No compilation error while moving BOM.
Sometime even no error occurs and code remains as is.
Please refer attached screen capture. (Sorry it is in Japanese )
Even IBM team is also not getting what exactly going wrong.
Any help would be appreciated.
Synchronization between Rule Designer and Decision Center is not perfect. Used to be unusable (ODM 8.6), then just terrible (8.7), then not bad (8.8), then only occasional issues (8.9). I've not used 8.10, but sync seems to be getting better, with fewer errors, every release. Publishing something new generally works well. The problems I've seen have been when updating something that already exists in Decision Center. I don't think I've had the problem you describe, when pushing a BOM from RD to DC. But I would be tempted to delete it in DC and try pushing it again. If that is not feasible, perhaps you have a second DC server running that you attempt synchronization with? Doing that could tell you if there is a problem with the BOM in RD or if the problem is with the original DC.
For this kind of problem, it is helpful to know what version of ODM you are using.
Related
I maintain a gtk3 (though a mixture of gtk2hs and gi-gtk) application that serves as a standalone status bar for tiling window managers called taffybar.
Taffybar has a long standing bug where something happens that causes one of its windows (it can have multiple windows e.g. when displaying on multiple monitors) to stop updating completely (issue here). I have verified through various logging mechanisms that the code that is supposed to be updating the window IS in fact continuing to run. Also, if taffybar is displaying on multiple windows, windows will become affected one at a time -- that is, the hang only seems to affect the window on which it occurs, which rules out anything strange happening on the UI thread or something like that.
Unfortunately, I do not have a consistent way to reproduce the issue. What's worse is that I haven't even been able to come up with a way to detect the issue programmatically. With that said, it is relatively easy to get the issue to occur as it has gotten much worse recently with the new icon loading mechanisms that have been added (it seems to happen about once every 5 minutes in the latest version). This reminds me that another thing I should mention is that I am relatively certain that the issue has something to do with pixbufs and image display because I have never seen the issue occur when the workspace images module is not active.
I hate to ask a question without even being able to provide a consistent way to reproduce the issue, but I'm simply at a loss as to how to go about tackling/debugging this issue. It's hard for me to imagine how the behavior that I have described is even possible, actually. I'm hoping that something about the idiosyncratic nature of the issue might be enough for someone more knowledgable about gtk than I to make some guesses as to what the issue might be.
To make my questions as explicit as possible I'll phrase it as follows:
What could cause a gtk application window to hang (stop updating) without crashing the application or the UI thread, or affecting any of the other windows created by the application?
EDIT: One more interesting quirk of this bug is that even though the window stops updating, it still responds to mouse input.
EDIT2: Another thing worth noting is that occasionally, I have gotten this message:
gtkicontheme.c:3956:proxy_pixbuf_destroy: assertion failed: (icon_info->proxy_pixbuf != NULL)
I have also gotten the following message when I attempt to destroy the hung window in code:
Source ID 363524 was not found when attempting to remove it
I am loading icons from the icon theme sometimes
I believe that the cause of this issue was simply that some UI updates were not being performed on the main UI thread. I can't be 100% certain of this because I was never able to reproduce. See this comment for more details:
https://github.com/taffybar/taffybar/issues/228#issuecomment-402591159
I have set up the color scheme to identify the different system of the building services in Revit and Navisworks. When I uploaded to the forge viewer, the colors were shown correctly at the beginning. However, when I zoomed in, some of the colors were disappeared. Did anyone have this problem? How could the problem be solved?
Thank you.
Forge Display Error:
Zooming Lo01
Apologizing for any inconvenience caused, this might be a known issue of our model extraction service for the Revit, it has been logged as REVIT-120524 in our case system to let our dev team to allocate time to investigate it. You can send this id to forge.help#autodesk.com to inquire updates in the future.
BTW, the reason caused this issue I discovered is there are many MEP system type, and they have owned different colored material, fittings will take materail color from the first system type from corrosponding MEP systems. Currently, there is not formal solution to avoid this. We apology for this again. Fortunately, there is a workaroud you could try:
Split your MEP models into servral RVT files that contain single pipe system, duct system and others.
Upload them to the Forge for translation seperately.
Load translated models via the Forge Viewer.
Hope it helps.
This workaround is working on my live projects now, but might not suite for you. And it's not the formal solution, you might have to use it at your own risk.
I must first say I have had a ticket open on DevExpress support for several days now with no resolution. I thought maybe other developers here have the same problem, and maybe even a solution.
While using the 30 Day Trial, whenever a DevExpress component is create, or something, an immovable and large dialogue pops up on the screen, on the same thread (I think) that created the component. If there is an error or breakpoint in the code that triggered that dialogue, all is lost. The debugger is unresponsive, and the evaluation dialogue is unresponsive. To make matters worse, it always appears centre screen, obscuring the error message, as in the image attached. My only recourse is to restart VS, but what then? The same debugging sequence has the same effect again. At this rate I will need 300, not 30, days to evaluate the product.
EDIT: I have posted a ticket at http://www.devexpress.com/Support/Center/Question/Details/Q534381, and they are working on it.
According to my experience, a Trial Screen is expected when using a Trial Version.
However, the mentioned issue is not a proper behavior and should be changed.
In any case, I believe that only DevExpress support can assist you with this issue and put you on the right track in the most effective manner.
If you has already posted an inquiry to the support, share the corresponding link here.
Once you get a valuable response from the support team, post a new answer here and accept it to close the SO issue.
During debugging a C# Consoleproject, about once an hour, I get the following error for a mind-boggling 20-30 seconds:
The weird part is that the source files are stored on a local SSD hard drive....
This is a workflow-disruptive completely unacceptable nuisance. Googling didn't amount to anything, do you know how to get rid of this?
Long delays are usually associated with network timeouts. There is one setting that can affect this. Right-click your solution node in the Solution Explorer window, the one on top of the tree, Properties, Common Properties, Debug Source Files. Verify that the list contains directories that are not stored on a disconnected network drive.
a mind-boggling 20-30 seconds
If you are sure about the length of the delay then it is not very likely to be a network timeout, it is too short. That kind of delay is associated with another scourge on programmers' machines, notably on an uptick in the past few months. It is the kind of delay you get from anti-malware. One of your files tripping the pattern of a known virus. The canonical example of such a problem is here. Also has a hint on how to detect it and the recommended workaround.
If none of this pans out then you'll need the help of the techniques outlined in Mark Russinovich's blog posts. Lots of examples of him using his tools to troubleshoot problems like this. A sampler is this post, doesn't match your problem but shows his approach.
This is really unknown issue to many people. I would raise a question for it and make it easily accessible for other, and maybe someone of you know the solution for this problem.
All of us probably know that there is problem with alpha transparency in PNG24 in IE6 (still used by many people on web..). There are at least few known solutions how to solve that, but all of them got their problem that I would like to describe there:
1.Using progid:DXImageTransform.Microsoft.AlphaImageLoader:
This is most common trick to make images shown in IE6. Problem is that it uses DirectX to show it. So basically DX firstly need to download file from Net, then render it. This downloading block browser context for a while. But if you have alot of images - that means that you page can be freezed for even... few minutes (it happens to mine one project at least once).
http://blogs.cozi.com/tech/2008/03/transparent-pngs-can-deadlock-ie6.html
http://www.stum.de/2008/12/01/do-not-use-alphaimageloader-to-fix-transparent-pngs-in-ie6/
2.Using VML.
You can also use this workaround. However this has a nasty effect of rendering gray box in background, then a proper image, also causing to download image files twice - this however might be because of bad implementation so need to be checked.
3.Using PNG8.
Just forget about solutions and try use PNG8, if prepared correctly can still be looking good.
If anyone knows any other solution please give answer here!
You should definitely have a look at http://www.dillerdesign.com/experiment/DD_belatedPNG/