Could someone please reopen case 50081? When the IDE crashes with that specific issue, that case is automatically appended to. There have been 8 updates to that case from users so far in June. We’re not choosing that case, so can you help us out? Otherwise we’re just wasting our time. I’ve asked a couple of times on Twitter.
The case was closed as a duplicate of another case, which is private.
I hope, requesting a Change of the Status in the Feedback App, will work someday…
It looks like we are. I’ve been trying to have this case reopened for a week now. All I was trying to do was make these reports (that are still being automatically added to the case when the IDE crashes in this manner) useful to Xojo, so that they have useful information to fix their product. But it increasingly feels like any attempt to use Feedback is a total disrespectful waste of my time.
We appreciate the additional notes posted. We’ve looked at all of them and still can’t find a way to reproduce this reliably. We’d love to fix it but have no idea what needs fixing.
The status has been changed so it’s closed not reproducible instead of as a duplicate of a private case (it’s now related to the private case). That should let it re-open automatically.
Thanks Jason. I understand that some things can’t be produced reliably, but customers are pumping reports into that case and it felt like a complete waste of time. Surely a case, with reports that often reference the currently shipping release, should be automatically left open, even if it can’t be reproduced? Perhaps it’s appropriate to close the report again when a further release ships, at least until a customer comes up with a new report on that release, at which point reopen?
What is the proper way to request a change in a case status?
Hi Gavin - We did it this way so that we dont have open cases laying around that we cant reproduce. Adding a note to a case should be re-opening it automatically.
For a status change you can click on the Status link. That should give you an option to request that it be re-opened.
That’s why I was suggesting that if they’re not reproducible, they get automatically closed only when a new release comes out. Not arbitrarily closed when someone can’t reproduce it , even though users continue to have the issue and continue to report on it. Adding to the case with a report of someone using the new release would then reopen the closed case.
That hasn’t worked for some time on Closed cases, at least for me. The menu doesn’t open when I click it. I click the Status link and I see the popupmenu in the drop down window but it doesn’t open when I click it. On a Mac here, latest updates and latest Feedback, AFAICT. It works fine for open cases.
Sorry, but LOL! Did you see the Screenshot above?
@Jason Parsley : you really want to tell us that you don’t even have a clue what is causing this problem? I get a mail from Feedback every couple of days. And surely most developers will stop sending stuff to Feedback after the first couple of crashes.
Let’s start with the basics: when does the crash occur. Looking at the descriptions it’s all over the place:
- in the background
- crash on quit
- importing a file
- clicking on a method
This is all over the place. 2017r3 and 2018r1. I seem to remember that even the 64bit IDE has some components that are 32bit. Is this a memory problem again? What threads are running always in the IDE?
You need to give us something that can help to reproduce this issue. Saying “we can’t do anything” isn’t really helpful.
Not sure if it’s important, but I recently was having a crash near __pthread_kill() - Not in the IDE, but in my compiled 64 bit macOS app.
The culprit was a call to lstat() where the memoryblock was too small because the structure was different in 64 bit builds.
But the crash was happening elsewhere in the app.
I wonder if the IDE is having a similar problem?
The solution would be to run the IDE under Instruments or perhaps MallocDebug (if that’s even still usable?)
Does Xojo do stack checks?
e.g. on begin of method fill a certain value into a stack variable and on end of method check wether the value is still there. Abort if value changed.
I didn’t say that it works 100% of the time I said that it’s designed to work that way.
For closed cases, this doesn’t work 100% of the time. Which is why I asked what we’re meant to do.
Ok. If it’s not working as it should, you can email the info. to me (email@example.com).
@Jason Parsley : There has been much criticism of the curent Feedback application. It is unintuitive and somewhat buggy (some would say utterly buggy and simply unusable - just repeating here what can be read elsewhere in forum posts) . It is obvious from a quick forum search, that the popularity of Feedback among Forum users is rather low.
Perhaps it is time to re-think (redesign) the application, at least the customer-facing part of the application?
While Feedback is not perfect, based upon the activity we see, its clearly being used a lot. Having said that, we are always looking for ways to improve it and are actively working on improving it.
Sure, it is used. We don’t have a better choice, do we?
Requesting a change of status for closed cases doesn’t work and hasn’t been working for a long time. I thought you guys knew. So, we email you with case status request changes now? Okay.
When I change the order of ‘My Top Cases’ like swapping my #4 to #3 it’ll occasionally swap one and leave the other blank. It doesn’t do it all the time…
Has anyone else seen that issue?
That’s fine. I may get overwhelmed but it may help to narrow down what’s going wrong in Feedback.