tinyMCE.execCommand accepts a boolean user_interface parameter, and I've been trying to figure out what the difference is when it's called with true or false. The source seems to call it with false consistently, and the JSDoc description says True/false state if a UI (dialog) should be presented or not.. I've tried calling it with true and false and don't notice anything different. What is actually supposed to happen or allowed to happen if it's true? Can an example be provided?
That parameter is no longer used in TinyMCE. It is a holdover from an older TinyMCE where this was valid parameter - its not been removed for compatibility issues.
Related
I'm learning Swift, using this guide from the official website, in the form of PlayGround.
And I had this error:
I'm so confused... for one thing, this is an introduction guide, for another, I tried all of these and none of them work:
Luckily I finally got this one to work, but I don't know why...
So, I think my question is:
Why there's an error?
What's the original thought behind this part of guide design? I mean, what do they want to show us originally, knowing it's incorrect...
In my working code case, I don't see I can change my code to what's showing in the original guide example of if condition using optional variable. There's no way for this code:
if let nickname {
print("Hey, \(nickname)")
}
to work, right?
Answering your questions:
There's an error because the Xcode version that you are working with has a Swift version <5.7 (Xcode <14) which does not yet support if let shorthand syntax for optional binding when shadowing an existing optional variable (proposed in SE-0345).
For your second image, you are attempting to use optional binding with an non-optional string literal "something", which is, in semantics, pointless, not to mention being syntactically invalid.
The original idea behind this part of the guide is to familiarize you with the idea of dealing with optionals, specifically "optional binding", which is a technique used to work with optional values. You might wanna look into that via the official Swift language guide.
Short story: Think of variables as boxes. In Swift, these boxes can contain a certain type of data (e.g. String, Int, Bool, etc.). All these types that you might be already familiar with are solid data types that guarantee something of that type will be present in the box. But in some cases, you will be exposed to (or need) uncertainties in which you have no idea whether or not a solid piece of data is present within the box. This is when optional values come in--boxes that do not guarantee the presence of values (this box can either have something solid inside or nothing at all, nil).
Usually, we can force unwrap the optional values, but that can cause an error in your program when the box has nothing inside (Swift be like: hey! you promised me that there's gonna be a value inside the box but there's nothing inside, you untruthful creature! what do I do now? *rage halt*). That's why you need an optional binding: you tell Swift to carefully unwrap it and do something with the potential value inside (if it can be safely unwrapped) and do something else when there's nothing inside. The conventional syntax is:
if let aValue = anOptionalValue {
// if there's something inside the box, do something with it
print("haha found ya", aValue)
} else {
// otherwise do something else
print("oh no! empty box...")
}
Swift will now be happy: "at least you warned me that it might be empty inside and told me exactly how to handle it."
You are trying to use the shorthand syntax for optional binding which is only available after Swift 5.7 + Xcode 14. You'll need to get a Xcode 14 beta to use it.
All parameters are always exported as "tunable" by FMUexport from Dymola. In many places this cannot be changed to "fixed" at all, because (sub)components from libraries are locked against it. So our next tool tries to use degrees of freedom which do not exist. Is it possible to reverse the behaviour so that all parameters are initially set as "fixed"? Or is it possible to set all parameters to "fixed" at once, even those in library blocks?
Two flags in Dymola come to my mind that could have an effect:
Evaluate = true
Advanced.EvaluateAlsoTop = true;
Both can be set via the GUI:
They do have influence on the definition of the variable in the FMU's XML file. They change "causality" and "variability". Though I'm not sure they do exactly what you want.
Likely it would make sense to set only Evaluate = true and propagate all the parameters that shall be "tunable" to the top level...
I wanted to use an NSButton's integerValue to pass on information in a method and ran into a curious bug: whatever I set a value to - whether integerValue, stringValue, or floatValue, when I read it out, it's 1.
NSButton inherits from NSControl and should have the usual set of values... but all of them, including strings, resolve to 1.
Nothing I can see in NSControl.h or NSButton.h points to xxValue being anything other than ordinary properties.
I'm working in Xcode 9/Swift 4/macOS 10.12.6 - is this a known problem? Is this documented anywhere? I've used .tag as a workaround but would prefer not to.
It’s not a bug.
From the documentation of NSButton:
For most types of buttons, the value of the button matches its state—the value is 1 for on, 0 for off, or -1 for mixed. For pressure-sensitive buttons, the value of the button indicates pressure level instead.
The attached screen shot says it all: I have a valid true Bool, I negate it with the bang operator, and (Xcode tells me) I have an invalid value.
It appears that this "invalid" value does behave as if it were false. But really, wtf?
I've had this issue in Xcode 8.3.1 and Swift 3.1 https://github.com/onmyway133/notes/issues/278
I tried
Clean build folder and delete derived data folder
Delete the app
Reset simulator
Restart Xcode
Restart Mac
But does not work. The workaround is to
let enabled = disable ? false : true
I'm no LLVM expert but I wouldn't be surprised about this behavior at all, unless optimization is set to Onone in which case it should have left your code alone. The intermediate variable is just asking to be optimized away, after all.
Got the same issue, with correct value for add code like print(theBoolValue).
But when use p in swift command line. Or just check the value in debug stack, the value become <invalid>(Oxfe).
just out of curiosity:
As you all might or might know, it is possible to set a custom BE logo with $GLOBALS['TBE_STYLES']['logo'] = '../fileadmin/mylogo.png'; in typo3conf/extTables.php.
This behavior is working since old v4.x times.
But I just read that extTables will be deprecated in v8.x.
I tried to find a simple solution to this (one that keeps that one-line simplicity and does NOT require me to create&install an extension!)
I moved this line to typo3conf/AdditionalConfiguration.php,
but it does not work from there.
Why?
What would be necessary to make this line work within typo3conf/AdditionalConfiguration.php ?
In TYPO3 8.x you'll be able to change a backend logo via EXT:backend, so you should stick to that approach. Read more in release notes.
UPDATE.
To answer your question, why TBE_STYLES defined in AdditionalConfiguration are ignored: take a look at unsetReservedGlobalVariables() method from \TYPO3\CMS\Core\Core\Bootstrap class. It is executed after all the configuration is initialized (Local and Additional are merged and populated) and explicitly calls unset($GLOBALS['TBE_STYLES']);.