Tag Archives: Feedback

A Xojo Existential Crisis:  When Self is Nil

Posted on by
2

A couple of Formatted Text Control users found an interesting bug in the Xojo Windows 64-bit compiler.  If the user pasted anything into the control it would hard crash the Windows application.  I spent a couple of days trying to find a workaround and was flummoxed on how to fix.  Thankfully there’s an easy workaround thanks to Team Xojo.

In the Open event of the FTC control we create a new FTCUndoManager instance.  When the user pastes something into the control we pass the existing text into the Undo Manager so it can properly save the before state and allow an undo of the paste.

Pasting text calls the SavePaste method of the FTCUndoManager class.  This is where things start to go wrong.  This method passes Self into the constructor for the FTCUndoPaste class.  Stopping the debugger in this method shows us that self is nil!  What’s odd is several other passed in class objects are nil too (even though they are not at the control level).  That self is nil is indeed a problem since FTCUndoPaste needs the reference to the UndoManager for a variety of reasons.

How can self be nil?  After all this is a method in the class.  By definition self should be non-nil.  I think this would fall under ‘compiler problem’.  I submitted a private Feedback report to Xojo (53967)  and thankfully Xojo reviewed it quickly and were intrigued enough to look into it.  It was verified and a workaround was quickly found.

William from Xojo wrote this:  

There seems to be an issue with passing byval structure parameters (for 64-bit Window build), as a workaround you can pass these byref instead, i.e. MyFunction(…, Byref firstPa as ParagraphAttributes)

So I was able to change two methods, FTCUndoManager.savePaste and FTCUndoPaste.constructor, by using byRef for each object we pass into the Undo Manager into and in the Undo Paste class.  Voila!  Problem solved.

I suspect that FTC is big enough and complex enough to manifest some edge case for the 64-bit compiler.  If you run into an issue like this try this workaround.  And don’t forget to submit a Feedback report to Xojo since the more edge cases they can find the more likely it is they can determine the cause.

Happy Coding!

Time Waster Feedback Reports

Posted on by

Someone on the beta list asked a good question the other day about things that cost you time when using Real Studio.  It’s a really good topic because some really good ideas come out of the brief discussion.  We were kindly reminded that there was no current beta and the topic is more general so I’m bringing it out into the light of day for those not on the beta list.

I have created a Shared Folder in Feedback where you can put your “Top Time Wasters” Feedback reports into for the world to see.  The Feedback link is <feedback://subscribe?folder_id=34>.  There currently about 20 reports in the shared folder that are worthy of your perusal.  A few examples:

  • Plugin compiling glacially slow (currently ranked 768th)
  • The compiler repeatedly prepares plugins.
  • Edit Code button should jump to exact position
  • Add version identifier to plugins
  • Debugger:  Visually mark values that have changed
  • Debugger:  Watchpoints (currently ranked 264th)
  • Debugger:  Show variable values as tooltip when hovering over it (currently ranked 11th)
  • Add Debug Run Default per project (currently ranked 1360th)
  • Standardize Format should be automatic

These are really good ideas that could make my use of Real Studio more efficient.  Feel free to add your own productivity enhancement ideas.  With a new IDE user interface coming there’s no guarantee that RS will use any any of these ideas but you can at least give them some feedback on what you want to see.  The fact that some of these are ranked already says that some already agree with the user who posted it.

My own personal feeling is that the debugger is woefully incomplete.  It needs some redesign and some features added to make our lives easier.  An old ARBP survey asked about things that people wanted and the debugger was a very high want after more powerful grids.

Feel free to add your own in the comments section below, but what would be better is creating a Feedback report and putting it in that shared folder.

Feedback Thoughts

Posted on by

I have a hard time falling asleep.  Always have and probably always will.  So I lay awake thinking about ‘stuff’.  Last night I started to think about the REAL Software Feedback system.  I have no particular beef with it – it’s just it doesn’t help me very much in certain areas.

I’ve used a lot of different bug reporting systems over the years.  Some are awful and some are really good depending upon the project.  Feedback is somewhere in the middle and I think a few changes would make it an outstanding system for REAL Software and for us users – particularly those that participate in the beta program.

First, add a category to the feedback report.  Just off the top of my head, I think these categories would be helpful:  Feature Request, Crash, Failed Assertion, Incorrect Functionality, and Incorrect Documentation.  This would be helpful for RS engineers in working on the really important types first (i.e. crash and failed assertions) and the rest later.

Second, I need to be able to say what version of REAL Studio I’m reporting against.  I often get a message from an RS developer asking what version of Studio I saw this in because they don’t see in the version they’re working on.  I’ve resorted to putting the version in the comments which seems kind of silly.  Feedback, as I understand it, is using inter-app communications to get the version of Studio.  As long as it’s running.  If it’s not running it uses (assumes?) the latest version.  Which might be incorrect.

I often report things when Studio ISN’T running (I just go up to the Finder search and type Feedback to open it quickly).  So I’m either reporting no version or against a possible wrong version.  It would be nice if Feedback recognized this and let me select from a possible list of versions.

I understand that RS will test it against whatever their most current version is, but to be more efficient I would think knowing what the exact version the bug is reported against would be more helpful than showing the latest version.

We now have incremental release notes.  Yay!  Maybe the Release version information should be in Feedback too.  Ideally, I’d love to get an email from the Feedback system whenever the version it was fixed in was released.

For example, I noticed in the latest release notes for R5 alpha 2 that a bug I submitted is supposedly fixed.  As the submitter I would like an email telling me that R5 alpha 2 has a fix for that bug/feature request and kindly asks me to verify that the it is fixed or not.  As the submitter, I should be able to Verify or Reject the fix.

Not being able to vote down a feature request is a long standing beef of mine, but I’ll not beat that dead horse today.  Perhaps the voting should be broken out into two categories:  Feature Requests and Bug Fixes and presented as such?

Well, that’s it for today.  Maybe tonight I’ll go to sleep quickly.  What do you think would be more helpful in Feedback?

RB Feedback Item 3218

Posted on by

We all have our pet bugs and the proper mechanism to express our desire for any particular item is to edit the priorities in the Feedback application and put it in your top five.  A few people can make a significant impact by adding a Feedback item in their top five.  I’m here to today to lobby for a particular bug.

<feedback://showreport?report_id=3218> Save as Version Control format kills external encrypted items with subclassing:  Because this one struck me this morning in a very, very bad way, I put this as my #1 priority.  If you use version control and if you have encrypted items (I use RSReport from Roth Soft) you sometimes get an encrypted file that becomes blank upon saving.  So when the IDE tries to open the project a second time it throws an error because the file was blank.  The trick is to keep a copy of the original file somewhere and replace it, or retrieve the good version from SVN.  Normally it’s a 30 second procedure but today it was an hour diversion.

Needless to say, it’s one of my hot buttons.  Since this one affects me every single friggin’ project I hope you would make it one of your priorities too.

Since we’re talking about Feedback items.  What’s your hot button item that causes you no end of grief?  I’m willing to use one or two of my priority items to put your Feedback item towards the top of the list.  So what is it?

Why the REAL Studio Feedback Application is Bad

Posted on by

The number of bug reporting systems REAL Software has implemented in my time using REALbasic has been astounding.  Of course, some of the changes revolved around the emergence of the internet, but still, I’m amused at the iterations.

There was REALbugs (?) that was a standalone app that I never really used because I was a newbie. It memory serves, it was very much a Mac OS 9-type application.  As to how well it worked – I couldn’t tell you.

Then there was the feedback web site that allowed you to sign on to a bug to ‘vote’ for it.  It was nice, but people would literally sign on to EVERYTHING which defeated the purpose of the voting system to begin with.

Then RS switched to FogBugz and abandoned all of the old feedback items.  Supposedly, it would make life easier on them and they’d be able to fix bugs easier and faster.  Unfortunately, it made bug reporters life much harder since we couldn’t search the database.  RS was inundated with duplicate items and it was hard to tell the good reports from the bad.

So, now, in the current iteration we’ve come full circle and we’re back to an application called Feedback and is part of the download package.  It’s better in most respects to the previous system other than that it’s an application which just seems….odd in today’s internet world.  But I understand why they did it and for the most part it works.

It’s user interface forces you to search for an existing bug before you can add a new one (that’s good!).  You can see the newest cases (handy if you’re evaluating a new version of REAL Studio), My Cases, Participating In, and My Favorites.

You can add cases to your favorites list by clicking the star at the bottom of the cases listbox.  But a not so well documented feature is the Priority List.

The Priority List allows us to prioritize our bug fixes and feature requests.  This supposedly gives RS some feedback into what we want fixed or implemented sooner rather than later.  It’s also weighted in favor of the Professional and Enterprise users (we can argue whether that’s a good or bad thing in another post).  There is an algorithm to it but when I had my conversation with an RS employee I didn’t take notes so I might be off on the actual numbers.

A Personal license gets a weight of 1.  A professional user vote gets a weight of 10 and Enterprise has a weight of 20.  So Enterprise users are 20 times more powerful than Personal licenses.  That doesn’t strike me as too off base since a Personal license is $99 and the Enterprise is $995 (again we can argue the logic of the weighting another time).

Perhaps the smartest thing they did with the priority system is that you only get five votes and if my memory serves (forgive me, this is the day I got the flu), I believe a #1 rank gets 5 points and the last vote only gets 1.  So you have to be smart with your priority list and to edit it, go to My Cases and click the Edit Priorities button at the bottom of the list.  A separate list of all the cases you have some interest in are presented and you drag reorder the cases as you see fit but only the top five are counted and in the list are bold.

You can find the current list by clicking on Top Cases which brings up the current list.  If you double click on the list item you can see the internal rank in the upper left hand corner of the report.  And this, in my opinion, is where this system breaks down.

The current #1 item is case 9433 (iPhone support).  While it sounds good at first blush, iPhone development is a big break from how REAL Studio works currently, and it requires a lot of intermediate changes and there’s no evaluation from REAL Software on how long it would take to implement iPhone support or what we would have to give up during that time frame.

For example, the current #2 item is case 738 (Controls and Window Backgrounds Flicker in Windows) and is a huge problem for Windows application and my guess is that it hurts RS when Windows users evaluate REAL Studio more than they know.  Would you rather fix this gaping bug or have iPhone support?  Me, I want and need, this bug fixed.

Unfortunately, there’s no way to vote an item ‘down’.  The current system is rigged to only tell how many people think it’s a good idea.  There’s no way for RS to get a feel for how many think the top item is a BAD idea, or don’t think it should be a high priority item.

I personally think iPhone support is a rabbit hole of time and money that RS could use to adding some nice features and cleaning up long standing bugs.  To support the iPhone REAL Studio has to add a number of very important things before it can begin to *start* development:  Cocoa (currently in beta), LLVM compiler support (currently in beta for RBScript) only, new editors, and untold engineering problems on three platforms (is that even possible?).

Cocoa has taken close to two years to implement and ‘new features’ have slowed down (partially from Cocoa and partially from our requests for more bug fixes).  RS has talked about LLVM compiler support – first with RBScript and then for the entire app and who knows how long that will take to get working 100%.  The other items?  Only the Universe knows.

I urge all of you to play around with the Feedback application and find your high priority bugs and mark them as such.  This is the only way (currently) to tell REAL Software on what your priorities are.  If you want iPhone support, that’s great, but I caution you to be careful with what you wish for.

Happy coding!