Feedback Case Number: 76744
https://tracker.xojo.com/xojoinc/xojo/-/issues/76744
Wouldn’t it be cool to have the IDE tell you when an Xojo issue that affects your code has been resolved? And maybe it could even support your internal issue tracking system.
Not a fan of this integrated into the IDE, but if anyone can donate some time to create a tracking tool it is not much complex, just find target Issues Tracker handle (e.g. peterwhatever) Download 2 trackers summaries (2 atom xml files), the open cases and the closed cases, load them and later load again (days later) and compare changes. if some some new closed one appear, some open was closed, show the entries as wished, and your personal tracker can call user attention to the new closed ones.
The URLs:
Change @user to whatever is your Issues Tracker user (e.g. peterwhatever)
Attention, the peterwhatever user is fictiticious, use your own.
The value of IDE integration is the ability to link directly to the portion of code affected by the issue. It wouldn’t add any UI overhead - just another type of notice down in the warning panel - and could easily be left unused by disinterested parties. 
I can’t think how it can be done.
An issue like “When I set the background of an oval to red it becomes blue, any other color works” was open, then few days later Xojo fix it. What you expect the IDE do “in context”?
When you find a bug and file an issue, you add the #Pragma LinkedXojoIssue 1234 into your code. This can be detected by the compiler and noted as to where the pragma is in the code, which lets it provide you with a warning/notice that can be clicked (just like any other issue noted in the warning/notice panel, like a syntax error).
Initially I wasn’t sure of this request Eric but it then dawned on me that I’m already doing this and have issue #'s sprinkled throughout my code as comments. Your request just takes what I’m doing and automates my current manual process. So in the end, yes, I’m all in and gave you a thumbs up on the issue in the tracker. Great idea and thanks for raising.
Thanks! It just sorta hit me as I was scanning through the release notes for the new version today. We’ve got this great IDE, let’s ask it to do more of the tedious work for us.
That’s a lot of traffic and added slowness to compile code. Every cmd-K will fire a web request (or a series of them) to the issues tracker. The trade-off seems negative.
A tracker tool people could fire like once a day would be better.
I believe we can follow individual issues. In fact, I just got an update notice that one of my feature requests / ideas for improvement is tracked to be resolved in the next release.
I don’t see the issue with this. Every web request would complete in less than 500ms if the API is correctly configured. It wouldn’t change anything to the total time of Analysis if the requests are done correctly using URLConnection.Send, which is asynchronous.
In my concept, the IDE and compiler contain the list of bugs fixed – because it only matters if they are fixed in the compiler, right? So there’s no need to fetch the list every time you analyze.
Cases closed in Tracker aren’t relevant. You would need to know the cases closed & shipped in the last x releases which could easily be included as an SQLite database shipped with each release.
Yes. The database would have a list of all cases closed and shipped up to and including that release.
It’s a big list, heh, but that’s what databases are for, and it’s not THAT much data; just a lot of IDs and possibly their URLs.
It could also be cached and not queried more than once a day as long as Xojo is still running.
Regards, Antoine
No, because is the bug is dropped by Xojo (and this happens, if they don’t understand it), then it’s important to know that it’s closed and not resolved.
Regards, Antoine
Fetching and caching of the Xojo issue list is unnecessary, because Xojo would know for certain what the list contains when they ship the new release. It would simply be a file included in the release itself.
If they chose to implement the user issue functionality, fetching and caching does come into play.
Good point.
Regards, Antoine
I don’t completely agree. What if someone is holding back on updating Xojo because a bug was discovered in a newer release.
Using project analysis would still work and tell the user a certain issue is fixed in version XYZ.
That’s an interesting point. My intent is to notify the dev that their code is affected by the release they are using.
Perhaps your suggested functionality could be invoked separately, on an as-requested basis. It might come off as naggy or unwelcome marketing to be told “your issue is fixed in a newer release”.
I don’t see it that way. If you are using #Pragma LinkedXojoIssue 1234 in your code it is because you want to know when it is fixed or closed, especially when relying on an older version of Xojo because of that particular issue.