Real Studio 2012r2.1 issues in High Sierra (10.13)

General
1

I just noticed that when I try to add any control to a window of a Desktop project in Real Studio, running on macOS 10.13, they all end up invisible, with a negative Top and Zero Height. Tried on two computers.

Does anyone have a solution or does it work for someone in 10.13? If so, there may still be hope for me.

2

Verified. Even if you set the Top, Left, and Visible states in the control’s Constructor, they still don’t show.

However, apps built using 12r2.1 do run properly on 10.13 from what I can determine.

3

Time to bite the bullet Thomas?

5

2013r3.3 does work if you still need Carbon.

6

I rather improve Arbed’s editor and use that instead of the current Xojo IDE and its inability to let me work efficiently (or work the way I prefer, and as it works in the older IDE).

I concur, so far. Though that’s not important to me. I can build my releases with recent Xojo versions. I just don’t like editing and debugging them in the Xojo IDE as it drives me nuts that I constantly want to use navigation methods that the old IDE offered and the new one still doesn’t get right, leaving me often to get disoriented.

7

Can I ask which? You can jump to methods like using the nav bar with cmd-shift-L and that seems to have improved my usability and speed considerably. I do understand the feeling of “it used to be so much better” though, iOS 11 gets me all the time.

8

Here’s a list of things that do not work for me well in the Xojo IDE:

  • There’s no history menu
  • Jumping to another identifier using cmd-clicking and then back often does not work, especially when the identifier is in another tab.
  • Right-clicking on items in the left browser to find their uses is often not possible because the Find command is simply not offered on all items.

These alone make it very difficult for me to navigate. I do not like having to re-type identifiers all the time, as my typing skills suck, even after doing this for 35 years (probably because I started on a PET keyboard).

I brought these particular issues up many times, yet nothing has improved. I don’t understand why. I’d be able to fix them in a day.

And there’s more:

  • The new IDE requires many more mouse moving and clicking for frequently needed tasks, such as when declaring new props and methods.
  • Every time I Debug, the right pane (showing properties and such) gets in the way of the debugger’s right half, covering up the values it’s showing. This, for instance, only happens for me because I do not use the IDE in full screen mode, usually, so my IDE window is fairly small. Those who always keep it at a width of 1920 px will probably never notice. Regardless, the right Props pane should not even be shown in Debugger mode, because it’s quite useless there. But me trying to convince Xojo to fix this? Like fighting windmills, it feels.
9

Thanks for the detail! I’m always curious how others use the IDE, sometimes I find out about neat tricks!
Sorry it doesn’t work well for your workflow :frowning:

10

Yeah, I’d be happy to demonstrate how efficiently the older IDE can be used. But I’m afraid that would only frustrate you :stuck_out_tongue:

11

Type code, run, have to click in the COde Editor to make change (or addition or delete or whatever yu c-want to do there).

And, many, many others.

BTW: Do not code in the latest (latests ?) Xojo version because the file format changed.

12

goto location in all versions of the IDE suffers from a fundamental problem
it just uses a string that represents a path to an item
and not a complete path - usually just the just the names separated by a dot (ie/ like Window1.method or similar)
so it fails gloriously as soon as there are overloads, methods with the same signatures as events and many other ways
these cases are a perfect illustration of this
<https://xojo.com/issue/6137>
<https://xojo.com/issue/14537>

And jumping to one tab and back will have the exact same issue in old IDE’s for the same reason

The file formats have not changed
Additional properties etc may be being written - which older IDE’s may not understand nor load - but the basic formats havent changed

And there ARE things that exist in the new IDE that do not and never have existed in older versions
You can remap the keyboard shortcuts as you see fit
You can override the built in code formatter if you want
It has a much better ability to be controlled from an external source (we make heavy use of this to do automated builds- not its not a command line compiler yet but this is way better than its ever been)

13

Norman,

thank you for all changes. I only wanted to warn people against the double version use (and you explain it far better than what I wrote): the last to develop and an older to compile.

14

and you can change the default properties of built in classes. (A big one for me :))

15

I share your pain Thomas.

I’m currently migrating a project from RB2007 to Xojo for Cocoa + 64 bit and it is unbelievable how inefficient and unproductive the Xojo IDE is compared to RB. It is also disappointing that its functionality still isn’t better (and in a lot of places a lot worse) compared to a version produced 10 years ago.

I have spent enough time with the Xojo IDE over the past 3? years to get over the shock of it being different. However, it just seems so badly designed in places. As they would say ‘up north’ - all fur coat and no knickers.

I quite quickly came up with the following list of issues which has plagued me over the past couple of days:

General
• The whole experience is sluggish.

Code Editor
• Xojo struggled to keep up with my typing (even in an empty project with one method).

 • The find is poor (no way to perform a step next / previous find within the current method).

 • No way to show the find results / errors panel in a separate tab. This takes away a lot of space from the code editor.

 • Context clicking a method and going to it replaces the current tab and there appears to be no way to automatically open a new tab. I was hoping that locking my tab would have done this but it doesn't appear to. You can of course use the Back and Forward options in the toolbar to get back to where you were but that means having the toolbar visible which then uses a lot of space.

 • Code folding is not as good as RB. The lines / controls are too far away from the code, clicking them doesn't work correctly when the editor is scrolled and they don't highlight correctly.

Window Editor
• Double clicking the window or a control replaces the current tab. There appears to be no way to automatically open a new tab.

 • There appears to be no way to set the FullScreen option that is available in the RB IDE (this is not the same as the FullScreen Button option that is present in Xojo). When I convert my RB project I now have a set of windows where the property is set but no way to control it within the IDE.

Navigator
• Actions available when context-clicking are extremely context sensitive (anal). For example, to add a window property I have to context-click on the window or the properties header if a property exists. This results in so much scrolling up and down compared to RB where you could context-click anywhere and perform actions based on the item clicked or its parent (ie: I could context click a Window method but add a property to the window). Luckily, some of this can be solved using the shortcut keys but we still have lost useful functionality.

Inspector / Library
This seems so poorly designed and is a massive step back from RB.
• Method declaration fields have been shoe-horned into the tiniest of spaces making their contents unreadable.

 • A shared Inspector / Library panel which means you have to make the panel a certain size to see everything - again, wasting space. Even worse is that the Inspector seems to have a massive margin on the left-hand side a lot of the time making the space available to the data entry fields even smaller. A quick comparison seems to indicate that RB can show the same information with an Inspector that is half the width.

 • The debugger variables panel has been shoe-horned into a tiny space. Why can't it use the area used by the Inspector / Library?

 • The code editor horizontal space is reduced by the width of the Inspector. Why?

 • There appears to be no way to get rid of the navigator when editing a window.

Some of space issues can be solved by hiding parts of the IDE. However, you soon find that you switch to another tab or perform an action and have to make them visible again.

Debugger
• The debugger variables panel seems to forget its scroll position when you go back up a level causing you to constantly scroll to find variables. This wouldn’t be so bad if it hadn’t been placed in the smallest area possible.

 • Sending executables to the remote debugger still seems slow (although it is much better than it used to be).

I read a while back that some of the inefficiencies were going to be addressed and hoped that things would be better by the time I had to commence this work. Alas, it does appear that no real progress has been made over the past few versions.

16

Here’s the workspace layout that I use that has allowed me to become pretty efficient while using the later IDEs:

In preferences, I set Double Click opens a new tab for the Navigator, set the palettes to floating and then place them as you see there. I then Squeeze the Navigator pane down.

17

I stated, four years ago and some times later too: “I am insecure” when I use Xojo. “Nothing gonna change my world”.

Takes an example. In general, I never know where my MouseCursor is when I am in the IDE: both navigating withing the IDE Code using the arrow keys and using the mouse and click in a word (still in the COde Editor).

On macOS (and OS X, and … since System 6, the one I used when I was working at Apple France, yesterday), when you click in a word and want to select more characters (to the left or to the right), you press the shift key (eventually cmd or option key), then one of the arrow key(s).
On Xojo Code Editor, that deselect characters from the double click selection. :frowning:
(usually from the left)

Worst (if possible): place the cursor in the middle of the code (where the Code Editor last line is not empty): press Cmd-Bottom-Arrow. Then, use the vertical scroll to check (why Lord must I check what happens in this circumstance ?) and move the scroll to display the Code Editor last line. Surprise: the last line is not selected. :frowning:

Weird.

And this have nothing related to how the Navigator behaves or why some properties (Cmd-i / Ctrl+i) locations changes from the used OS (think macOS / Windows).

This whole discussion is a mess: “Nothing gonna change my world” (The Beatles, Let it Be, 1968-1969-1970).
[Yes, I love The Beatles, and many others too].

18

So, has anyone found a solution (i.e. workaround) to makeing the RS IDE work under High Sierra?

If not, I may soon have to find my own way (which I won’t be able to communicate here, as Xojo Inc does not like their paying customers to fix bugs in their old or current software even if they lack the interest to do it themselves).

19

How about a macOS VM with an older macOS?

For testing I use VMWare Fusion with macOS 10.5 up to macOS 10.13.

20

Thomas, where’s the sense in that? I don’t want to do my entire development in a VM. I mainly use the Mac for development. Why would I update to 10.13 and then do almost everything in the slower VM?

21

If it involves modifying the Xojo binary, then you are correct as that would be a violation of the EULA.

I understand your frustration and we are working on making some big improvements to IDE navigation but they have required fairly extensive foundation-level work that is just now finally being completed. Stay tuned.