I've experienced and witnessed several cases of Dev Studio just... disappearing... from my and others' screens while doing day-to-day stuff like opening a fex in an external editor, use feature X or just use it for any length of time. I've seen people complain on the forums that it crashes for them. I'd like that fixed, but I'm not getting anywhere.

I have a case open with IBI about one of these issues (see below), but since the tech support contact "cannot reproduce" my issue on his system, he "can not take it to development"... All I get back are irrelevant and often downright stupid requests for information that is NOT going to solve these issues.

I've put forward several suggestions to debug how Dev Studio handles memory allocation and similar "stuff", but since I'm talking to a tech support guy and he "needs" a reproducible test case to "go to development", that's not getting me anywhere! Rather frustrating.

I've been asked to provide a VMWare image even! Provided I could recreate an environment where Dev Studio crashes like it does here, and that remains to be seen in a freshly installed VMWare environment, that would cost me much more time than I can afford to spend on it. As I see it, they have a bug in their product, they should be spending time to find and fix it - Not me.

As I know I'm not the only one struggling with Dev Studio stability issues and, quite possibly, IBI tech support, maybe if we unite we can convince IBI that they need to fix the thing?!?

So, is Dev Studio crashing for you or not? What version are you using on what OS? Under what circumstances does it crash (provided that it does)?

In my case (#72782512), it crashes every time that I open a fex with gVim (7.3 32-bit) from the context menu in Dev Studio, on Windows XP (both SP2 and 3). I have gVim associated as the default program to open .fex files in Windows explorer. I just right-click a fex, choose "Edit in Vi Improved - A Text Editor" and I'm looking at my desktop where Dev Studio used to be.

This message has been edited. Last edited by: Wep5622,

Wep

I'm on 7.6.10 (I know it's old, but that's what my current customer is on). If I try to open a fex with Notepad++ from the DS Environment nothing happens. However, if I choose to display the Windows Desktop (which is not the desktop really, rather the file system) I can double-click a fex and it opens.

When it comes to DS crashing, I think we all have seen that once or twice or ....

A number of times I've had to restart DS, just because you can't do anything. E.g. you can't save a file. It's very frustrating when you press the Save button, and the sign for a changed file disappear, and you exit the editor, just to realise it did not save the changes. Probably it is resource-related thing.

I do second your opinion, we should not have to do the testing, IB should do it. Otherwise they should pay us for it, not the other way around.

Håkan

They should compile all the comments made about DevStudio in this forum - we can't all be imagining the crashes and other odd behaviour we see every day.

We've used dev studio since ver 4.5 and the only time I can ever recall DS crashing for an unknown reason was we had a program that had a comment line ("-*") where the dash did not start in column 1. We also avoid the GUI if at all possible.

I'm having this problem with 7.7.03. It is very sporatic and i have not determined an event that might trigger - so I have not opened a case with IBI. I have opened almost 20 since going to this release.

Dev Studio 7.6.8 on Windows XP with updates. I've determined no specific pattern, but I've experienced crashes on this and past versions of Dev Studio on multiple machines (owned by multiple users) with varying horsepower over the last six years. The problem is dramatically worse on some machines than on others, and it becomes more likely to occur the longer Dev Studio is used.

The problem is not a resource issue in the sense that none of my other programs stop functioning properly under the same conditions.

I agree - IBI programmers should fix the problem! We all know finding bugs can be challenging, but a challenging problem is not not a problem!

Rob

I am using 7702 and this server crashes all the time.
I have other applications running on the same machine as well but they dont have any issue.
Each time thw WF server crashes i have to restart the machine and that brings the server up.
I opened a case at support and they suggested to do a fresh install of the WF. i dont understand why.

I notice that IB rarely comments on the numerous complaints about Dev Studio and more specifically HTML "Composter". I can only assume that instead of fixing earlier versions they are concentrating their energies on WF 8.0 which I hear will be a radically different product ....

Yes, an overhaul in version 8 is much anticipated, but from a customer-service perspective it is not good to be playing coy with the clients when they report that Dev Studio has stability issues.

We've been using WebFOCUS since the 4.3.5 days and IT IS WELL-KNOWN that DS will periodically just "poof" disappear from memory and crash without so much as a Windows exception dialog.

It does call into question the error-handlers that are built into the tool.

C'mon, IBI -- at least engage in honest dialog with the customer base. We who live with the authoring tool on a daily basis are well aware of the quirks, and it would be good to acknowlege this, rather than add to the frustration by making it seem like these are isolated to the client side....

Dan in Omaha

Hi Wep, I have reviewed your case with Developer Studio crashing whenever you try to open a file with the Vim editor and although not reproducible from our side it is an issue that needs to be addressed and in your case it occurs consistently.
You make good points, the product should not crash and a message should be displayed when a failure occurs.
I have discussed this with our programming group, they agree with you and they examined the part of code that opens an external editor for possible flaws. They were also surprised that no error was generated.
Programming found cases where a stack overflow can occur and made code changes to prevent crash and return a message when a failure to edit the file occurs.
We will provide a hotfix with these changes so we can see why issue occurs and also correct the crash issue.
The case you opened will be updated with more detail about the work being done to prevent crash, events we check during the file edit operation and messages that will be returned in case of failure.
Hakan, I am also reviewing the issue with Notepad++. I have not used this editor so far.
For other issues causing crashes, we definitely don't want this behavior and we strive to prevent it.
Any info you can share to help us debug issues that causes other crashes is welcomed and will assist us in debugging and fix instability issues.

Thank you.

That's excellent news Dimitris!

A stack overflow sounds just like the thing that could have caused the crashes that (actually quite a few) people are complaining about. Well done tracking that down.

Usually after a while of them not being able to reproduce a problem, I have them do a remote session where they can see my environment and I show them how it is behaving. 90% of the time when they see what the problem is they can at least write it up with my system specs and turn it in to programming. I also found that if my Dev Studio was crashing a bunch I could get past it by installing the next version up as long as it wasn’t a major change. Note doing this may get you into situations where the server does not support a function that the client offers.

I wish I could say that I have been able to work up a reportable case over the years with Dev Studio crashing. There have been no established patterns that have occurred to reproduce it on-demand, so that we could benefit from even a remote session. The frequency happens perhaps once a week from an installed base of 10-15 developers.

Over the years, we have come to expect an intermittent "poof" crash, it just unloads from XP without a trace. It does seem to be related to 1) having DS up and working for awhile and 2) performing some Managed Reporting tree functions (copy, new procedure, etc) or edit functions.

We also have noticed that now under Windows 7, it doesn't "poof", we just get Windows 7 telling us "The Focus Development Workbench has stopped responding".....which is essentially the same as a "poof" crash in XP, in my eyes.

I admit that I have never been able to understand a lot of Dev Studio's quirky inner-workings -- why we can have our MR authentication Cookie totally stale for hours, yet still be able to perform MRE copy operations with a right-click drag-n-drop on the MR tree. I have also thought that DS suffers from massive bloat-creep, trying to be all things to all people, so they don't have to leave Dev Studio (do we REALLY need icons for Reporting Server Console, WF Admin Console, etc inside DS?).

Anyway, I will strive to be able to package up a case when our users report Dev Studio crashing. I am impressed that product development directors from IBI are engaged and attentive to this need and to the Focalpoint forum. The accessibility with your customer base is one of Information Builder's greatest strengths -- please know that it is very appreciated!

Regards,

Dan in Omaha
University of Nebraska at Omaha

I have seen Dev Studio do some crazy things as well. Right now I am experiencing it crash, but it does give an error message.

Steps to make it crash.
1. Run fex output type html
2. make edits
3. either save or not save changes
4. Run fex again
5. Crash.




Running Dev Studio 7.7.02 on Windows 7 64bit

In order to get a vendor to look at an issue, a case should be opened with the Support staff. They will then work with you. That is the first step.

Did you try running thisfoci.bat to re-register the dll's with Dev Studio? That has helped us in some cases, although I can't speak for 64-bit Win7.

I forgot to reply with a resolution to my previous post.

The error was due to a report I ran which the output type was EXL2K. Excel 2010 was prompting me if I wanted to open the .xls even though the file structure was a .mht but with the file extension renamed .xls. The Excel prompt was behind all other windows which somehow created a problem with focshell.exe, kernelbase.dll, and the C++ runtime library because it was still waiting on user/my input.

So long story short, the problem is resolved, not fixed, and I need to be a little more observant for Excel screaming at me when running reports. I am not sure if the problem is with Dev Studio or C++ runtime or both.

Cheers!

App Studio anybody? (<--- This Guy)

I just spent a half hour with a colleague to evaluate whether we should go with Dev Studio 8 or App Studio 8 and we chose the lesser of two evils - Dev Studio 8.

This is because we have dozens of HTML Composer designed pages with and without custom jQuery and references to CSS and JS files that are in a web server approot folder.

Open an HTML page in the App Studio GUI. Click the Save button (making no changes). Run the page. It fails because the references to the CSS and JS files are broken (the dreaded rtfilename rears its ugly head).

99.99% (give or take .01 -- preferably round up) of the time the HTML Composer tool seems to be causing this for us. Maybe the topic should be renamed to HTML Composer instability causing App/Dev Studio to crash (or preferably something with some humor).

-EDIT: Maybe instead of reproducing the issue someone from techsupport can watch a developer for a day and cringe as the tool crashes 5 (or many more) times throughout the day. The tool would be much better if it didn't do this.

This message has been edited. Last edited by: J,

There are no "developers", only "users".

I second J's comments.. HTML composer is clunky.. Every time I save, it hangs and brings up the Script Editor... Have to close it and then go back in.. (It does save..)

My associate's instance of App Studio crashed over 20 times today (he tallied it up). Several times he had to redo whatever he was trying to do becuase it crashed before saving. Pretty much all of it happened while working in HTML Composter (that term seems to be more fitting than composer today).

Hi

This is an extremely difficult issue to troubleshoot as you all have noticed no specific issue that is causing Dev Studio or App Studio to crash in such a manner. Traces do not help unless you have the traces on when the tool closes. Normally we have to reproduce the issue for the programming department before they will review a given problem which is very justifiable. Every developer has been plagued by inconsistent behavior of a program at some time. When a user comes to you and says they have a problem go fix it that can be frustrating and you have to dig into the issue usually before you can even begin to solve the problem, and that is what a reproduction is for. The reproductions save a lot of time troubleshooting for the programmers.

Dimitris and David are aware of the issue and would like to resolve the problem. Both are very competent and will find a solution.

Any time you can document a consistent behavior for the crashing please let us know and we can communicate with the division.

Thanks Barry Solomon

This message has been edited. Last edited by: BarryS,

Oddly using the suggestions from your post significantly reduced the amount of crashing. Previously he had been using the thisfoci.bat approach, now he uses the -r command line approach.

Greetings,

Perhaps this thread should not be marked [CLOSED], since it is obviously NOT a "closed" issue.

We at Univ of Nebraska have used Developer Studio since version 4.6. It has periodically crashed for a cross section of users/developers for the past 15 years. At times it seems to have become better and other times worse. HTML Composer is notorious for crashes (is it because it is still dependent on IE in "publisher mode"?). Yet I am using DS 8.008 EXCLUSIVELY IN TEXT EDITOR MODE, and it still crashes on me quite a bit.

App Studio 8.008 seems to be equally if not more unstable. Understandably, this is also due to it being a new product. But I recall attending earlier Summit sessions (2012) when App Studio was first trotted out, and we spent an inordinate amount of time dealing with instability in the labs.

Here's a suggestion for product development (Dmitri, David G, etc.) --

Perhaps you are have far too much functionality you are trying to wrap up in this authoring tool. It's really a telling statement that the footprint FOR INSTALLATION EXECUTABLE is a whopping 1.2 Gigabyte file. When you try to put this much complexity/functionality into the tool, especially with it's dependency on Microsoft quirks, trying to do everything under the sun from managing a WF environment from the desktop to authoring HTML to meta data management via a GUI -- and still strive to maintain backward compatibility while introducing new UI interfaces like "the ribbon" -- is it any wonder that this software has produced issues over the years?

Concrete suggestion -- start breaking it up into manageable pieces. Instead of one monolithic (and monstrously complex) authoring tool, give us different tools to manage different tasks. A dedicated HTML composer. A dedicated meta-data manager. A dedicated Text Editor. A dedicated Report Painter. Perhaps then you'll be able to isolate the memory management problems, Windows calls and other issues that seem to create our friendly "This program has stopped working". Sure, there will be a sacrifice of convenience to the user/developer because everything is no longer rolled into one big environment. But perhaps that is a reasonable trade off. Have you done user/developer research on this kind of a tradeoff?

And please, provide us with the ability to actually render in the registered web browser on our OS -- whether it be Firefox, Chrome or IE. The little "internal HTML renderer output window", though faster on launch, is not a sufficient substitute for a mature web browser (you can't even use the windows clipboard !). I know first hand that this has been asked for from the user/developer community for years. Still waiting for delivery of this feature.

My thoughts,

-- Dan in Omaha

University of Nebraska at Omaha
WF 8.0.0.5 (Prod)/8008 (Test)

Rigel7,

Interestingly enough, many customers and internal personnel feel the opposite. App Studio is much more stable in its 3 year existence than Developer Studio in it 20 year existence. This makes more sense since many core internals were changed to achieve this.

Have separate tools is not the strategic direction and is something customers complained about for Developer Studio - everything is a separate tool, and they all look and feel different. That is a main premise for the creation and paradigm if App Studio. There are no separate tools.

As far as invoking other browsers goes, it is coming for App Studio, however, you need to be careful of what you wish for. IE is integrated into Windows which allows for excellent cookie management. When you Logon to WebFOCUS and the Reporting Server, it is remembered so you are not prompted to login even if you close the browser. The same will not be true for the other browsers. We have advertised this and customers have responded that this will be ok. However, we believe once customers experience it, it may not be so "Ok" after all, however, there will be no alternative. This is why it has not been implemented for all this time.

quote:

Originally posted by David Glick:
Rigel7,

[...]

As far as invoking other browsers goes, it is coming for App Studio, however, you need to be careful of what you wish for. IE is integrated into Windows which allows for excellent cookie management. When you Logon to WebFOCUS and the Reporting Server, it is remembered so you are not prompted to login even if you close the browser. The same will not be true for the other browsers. We have advertised this and customers have responded that this will be ok. However, we believe once customers experience it, it may not be so "Ok" after all, however, there will be no alternative. This is why it has not been implemented for all this time.

Hi David,

How much harm could it make if it was set as default for IE and had a checkbox to select other browsers? It would be up to the developer so I doubt you'd have many complaints about it.

Thanks for the response.

quote:

Originally posted by David Glick:
Have separate tools is not the strategic direction and is something customers complained about for Developer Studio - everything is a separate tool, and they all look and feel different. That is a main premise for the creation and paradigm if App Studio. There are no separate tools.

I'm quite certain that that's not what Rigel7 meant with 'separate tools'. All those tools that in your view are separate are still built into the same Developer Studio IDE; a single tool. They are not separate at all, you can't execute them independently.

What I would appreciate would be to have a Windows file-system driver for IBFS, so that we can apply the tools we prefer to the various reporting files. Add separate tools for HTML Composer, Report Painter, etc. to that and we have the same capabilities and less restrictions on what we can do and how. Extra benefit, since the files reside on an actual file-system, we can use our source control system of choice (Mercurial/Hg) with it. And for people who like IDE's, it's still possible to tie those separate tools into an IDE to make them behave as a single entity.

I'm sure people coming from a UNIX background will recognize the pattern described above .

Diogopc, the developer will select the browser to use for "Run". That does not resolve any credential prompts though.