Member
Last active [hidden]
Not yet, but they're working on an open project file format, so if that's finished you can use any VC system you like.
Currently that's not possible, but I know they're working on exciting new professional features like debugging and an open project file format. That last one is what you're looking for.
For those interested I have attached my first own theme. I won't say it's pretty, but I personally like soft colours. Feel free to adjust it.
@marco @Marc please let me know if you build some cool theme to share with other users!
It won't certainly be cool ;), but I'm working on it now.
I already have a new feature request :). A refresh button that reloads the theme in the preferences. Now I have to reopen it every time I changed something in the external editor ....
@marco Hi @Marc, we added themes customization in the latest Creo version: https://docs.creolabs.com/technotes/themes.html
I (of course ...) already have seen that :)
iOS has Background Fetch that allows you to run code when the app is in the background. This allows you to for example refresh data and/or send local notifications.
This is not the same as the Timer control, as with Background Fetch the interval is determined by iOS (based on app usage by user).
I now have 2 panels: CODE and DESIGN. If I want to change that I have to first set one to LIVE before I can choose an other option. This is a bit cumbersome from a user perspective.
What I'm suggesting is:
For functions that need to compare/find a string, I would like to have the option to have it work case insensitive.
This now doesn't work:
"abc".replace("A", "X") // doesn't replace "a" with "X"; expected result: Xbc var list = ["a", "b"] var result = list.contains["A"] // result is false; expected result: true
In other languages, like .NET, you can pass an extra StringComparison enum parameter, with an argument like "InvariantCultureIgnoreCase".
In my experience most string operations need to be handled case *in*sensitive.
The zoom steps (Cmd +/-) are +/- 100%, which is a bit high for me. Maybe +/- 25% would be better.
Example:
var x = 1 var y = 0 if (y == 0 or x / y == 1) { }
In this example we have 2 expressions in the if-condition using "or" as the logical operator. If the first expression is true, then the second one doesn't have to be evaluated. In this case it *is* evaluated, resulting in a "Division by 0 error".
The only work-around is using 2 nested if statements.
NB: In this example I'm using a division expression, but it's also suitable for many other expressions.