I like to support the If() terniary operation in Arbed, which uses RbScript.
Unfortunately, there seems to be no way that I simply offer that as a function via the Context.
Since Arbed is still not Cocoa-ready, I am currently building it with Xojo 2013r3.3. But that doesn’t support if() yet.
I see that 2015r2 does, but since that requires Cocoa, I like to find an earlier version that supports if() in XojoScript.
Does anyone know when it was added?
Xojo 2014 Release 1
Confirmed. Thanks!
Oh, and even better: RbScript has gotten this operator added, too! That means I can keep editing and testing Arbed in RB 2012r2.1 and don’t have to worry about manually changing my script handler’s super class from RbScript to XojoScript every time I build a release 
What part isn’t playing cocoa friendly… The editor?
What, in Arbed? Yes, the editor doesn’t work so well in Cocoa because of the Keydown event not working with composite character input (´ plus e does not create é), and there are some issues with the focus rings. Not sure what else. Most parts seem to work. Maybe I just start building a Cocoa version and lets other tell me what they find not working
There are definite differences between Carbon and Cocoa when it comes to visual confirmation, especially for drag and drop. See https://forum.xojo.com/14202-drag-border-vs-focusring-visual-cues-and-drop-file-selected
Is the 'e é a behavior of your keyboard layout, or something you have implemented ? I do not remember for Lion, but in Yosemite as well as Mavericks, accented characters that do not appear on the keyboard are obtained by holding the character until a small horizontal contextual menu pops up with all available characters to chose from. The only keys I have on the French keyboard with two keys entry are ¨and ^.
Yes if you hold the key a contextual pop up appears with a set of letter to choice.
But you can always use the dead keys: alt-x then the key
alt-9 for `
alt-8 for ´
alt-u for ¨
and so on…
On my Yosemite system, when I type ´ or ^ on my German kbd or when I type Option+u for ¨, the common editfield shows that character with a special background color (eg. yellow) and waits for another key type. When that’s a vovel, it combines them into one. Has always been that way and won’t change any time soon.
The problem is that the code editor I use in Arbed needs to learn about every keydown and write it to its own Canvas. Now, if the user types the ´ (or ^ or ¨or whatever else causes it to wait for another key to combine with - it’s also called a “dead letter” key), in Carbon I would not get a keydown event. then, when the user types the second key, it would create a keydown for the combined keys. That doesn’t look perfect in my code editor because you won’t see the dead key show up in the editor until you typed the second key, but at least it worked when typing blindly. With Cocoa, I get the dead key as a unique keypress immediately, and so my editor can’t tell the difference between typing “é” and “´e”.
To solve this, I’d have to use the special input plugin provided by Xojo somewhere, and that’s a lot more of an effort than simply trying to keep Carbon working as long as possible.
[quote=189501:@Antonio Rinaldi]Yes if you hold the key a contextual pop up appears with a set of letter to choice.
But you can always use the dead keys: alt-x then the key
alt-9 for `
alt-8 for ´
alt-u for ¨
and so on…[/quote]
I am sorry, this does not seem to work here under Yosemite 10.10.3. By “Alt” you mean Option, right, as it is written on the key ?
Option-9 French keyboard = Á US keyboard = ª German keyboard = }
Option-8 French keyboard = Û US keyboard = German keyboard = {
Option-u French keyboard = º US keyboard = ¨ dead key German keyboard = ¨dead key
Yes alt, option (the key between ctrl and cmd or cloverleaf) on the Italian Keyboard these are the dead keys
On system preference you can turn on (keyboard > keyboard > show keyboard viewer on the menubar) then you can use the icon to view the keyboard on a floating window and using the "alt, option , whatever you call it) key, you will see these dead keys. As Thomas wrote “Has always been that way and won’t change any time soon.”
[quote=189512:@Antonio Rinaldi]Yes alt, option (the key between ctrl and cmd or cloverleaf) on the Italian Keyboard these are the dead keys
On system preference you can turn on (keyboard > keyboard > show keyboard viewer on the menubar) then you can use the icon to view the keyboard on a floating window and using the "alt, option , whatever you call it) key, you will see these dead keys. As Thomas wrote “Has always been that way and won’t change any time soon.”[/quote]
It appears the French keyboard has no such option key dead keys.
I see the German one has quite a few ones on top of the keyboard.
I looked at what happens in KeyDown for a TextField in Cocoa when using the dead keys. Indeed keydown fires for the dead key, but key is “”. The second one is the accented one, for instance é. So it looks close enough to what you describe in Carbon, maybe you just need to put an if key <> "" at the beginning of KeyDown.
Use Visualiseur de caractères and Visualiseur de clavier on your French Yosemite.
I know nothing about holding a char and getting a popup.
[quote=189522:@Emile Schwarz]Use Visualiseur de caractères and Visualiseur de clavier on your French Yosemite.
I know nothing about holding a char and getting a popup.[/quote]
I use US English Yosemite 
Holding a key is becoming a universal way of getting accented characters common to OS X, iOS and Android. Press for instance ‘e’ and hold the key down for half a second. You will get a choice of éèêë??? in a contextual menu.
Very convenient to get accented uppercase characters on a French keyboard that has none.
Windows has not copied that yet
No, I do not get that.
Windows 8.1 and OS X (since long time, in the version 6 or older) had a visual keyboard that let you see the other characters that the OS let you get (using sticky keys).
Even the Apple IIgs had that (back in the 1985-95 years )
In short on a French OS (OS X) / Layout, use Option-Shift-1 and place a, e, i, o, u, vowel to get á, é, í, ó, ú even ÿ and , Ã, Ñ, Õ (and lower cases are accessibles from the keyboard.
I re-checked (10.10.4 pb, FR) using this time TextEdit, I get a PopOver with what you say.
This is why the TextInputCanvas plugin exists. The IDE needed to be updated in the same way when moved to Cocoa.
[quote=189502:@Thomas Tempelmann]
To solve this, I’d have to use the special input plugin provided by Xojo somewhere, and that’s a lot more of an effort than simply trying to keep Carbon working as long as possible.[/quote]
To be honest you wont get the special editor behavior without using the text input canvas as a starting point
Its here https://github.com/xojo
Yes, the TextInputCanvas. But changing CustomEditField to support this will require a lot of work, I am afraid. And since I didn’t write this code, it’s double difficult to dive into it. I just don’t have the energy for that right now.
I still hope someone else will eventually make CEF work with the TextInputCanvas plugin.
Also, it would break everyone’s code that uses CEF right now, too. They all would have to start using this plugin.
That’s one reason why I begged about 12(?) years ago to have a way to conditionally compiled on the presence of plugins. And have a “#ifdef” pragma. I am not feeling very encouraged to break other people’s code just because Xojo can’t do what more popular languages can do. Sigh.
Actually, the problem with TextInputCanvas starts already with the fact that there is no ready-to-use plugin! How can I expect CEF users to migrate to this plugin when there’s no plugin they can use? I can’t expect everyone to install Xcode or Visual Studio and then figure out how to build this. Mind you - since CEF is x-platform, and since there’s no conditional compiling checking for presense of plugins, non-Mac users cannot even use CEF any more without making changes to it. And I have no idea how to build plugins for Win and Linux, either.
There is a binary plugin… I’ll upload and share the link.