I’m working on a little optical-illusion app. As part of that, I have a model key (a CGFloat) representing an angle.
I have three controls — an NSTextField, an NSStepper, and an NSSlider — each bound to that model key. (The NSTextField was created as a “Text Field with Number Formatter”.)
I want that angle to fall between -45 and 45 degrees at all times. I also want it rounded to the nearest integer.
To that end, I’ve implemented a setAngle method that applies those rules. In addition to rounding its input, it replaces any value falling outside the acceptable range with the closest valid value.
I notice that whenever I use one of the controls to change the angle’s value, the other two controls reflect the post-processing value — but the submitter itself does not.
For instance, if I move the slider, the text field shows the rounded value, not the possibly-fractional value that the slider submitted.
Likewise, if I enter 44.5 in the text field, the slider’s position corresponds to 45.
However, the submitting control still displays the “raw” value it submitted: the text field in the last example continues to read 44.5.
Placing
[self willChangeValueForKey:#"angle"];
and
[self didChangeValueForKey:#"angle"];
around the code in setAngle that actually changes the value had no effect on this.
My principal questions, then, are these:
Is there, generally speaking, a “correct” way to alter a value submitted by a control, such that all controls bound to the key get the updated value? I'm not entirely sure that angleSet is the right place to pull the sort of post-processing shenanigans I am, but I'm even less sure where else I should do so. (The Apple docs regarding validation in key-value coding expressly discourage using validation to this end.)
If there's no general-purpose mechanism for setting a tweaked version of model key, and notifying all associated controls after the fact, is there a way to identify the single control doing the actual setting, and update it with the post-processed value?
Thanks in advance!
use cocoa binding is the most easiest way for this situation.
declare a property
#property CGFloat angle;
and bind it to value of the controls with keypath angle or someobject.angle (it depends on your implementation)
Related
If I have an NSTextView which is in this state:
How can I tell the textview that if a user presses shift+right, that rather than extending right towards the 'o', it instead de-selects the 'e'? I though this had to do with the affinity, but I have tried setting it to both NSSelectionAffinityUpstream and NSSelectionAffinityDownstream via the following code:
[self setSelectionRange: NSMakeRange(9,6)
affinity: x
stillSelecting: NO];
But that made no different. Hitting shift+right still selected the 'o'.
NSTextView knows how to do this SOMEHOW, because if you cursor position between 'w' and 'o', then hit shift+left until it matches the screenshot, then hit shift+right, it matches the behaviour I mentioned.
I'm ok to override the shift+arrow code and roll my own, but I would rather allow NSTextView to do its own thing. Anyone know if I am missing anything?
I'm not sure what you're trying to do, since this is the default text movement/selection modification behavior. Are you trying to override this to always do this one thing or are you trying to add another keyboard shortcut that overrides this behavior? In either case, some background:
Selection affinity doesn't quite work the way it sounds (this is a surprise to me after researching it just now). In fact there seems to be a disconnect between the affinity and the inherited NSResponder actions corresponding to movement and selection modification. I'll get to that in a moment.
What you want to look at are the responder actions like -moveBackwardAndModifySelection:, -moveWordBackwardAndModifySelection:, and so on. Per the documentation, the first call to such selection-modifying movement actions determines the "end" of the selection that will be modified with subsequent calls to modify selection in either direction. This means that if your first action was to select forward (-moveForwardAndModifySelection:), the "forward end" (right end in left-to-right languages; left end in right-to-left, automagically) is what will be modified from that point forward, whether you call -moveForward... or -moveBackward....
I discovered the disconnect between affinity and -move...AndModifySelection: by looking at the open source Cocoatron version of NSTextView. It appears the internal _affinity property isn't consulted in any of the move-and-select methods. It determines whether the selection range change should be "upstream" or "downstream" based on _selectionOrigin, a private property that is set when the selection ranges are modified (via the -setSelectedRange(s)... method or a mouse down / drag). I think the affinity property is just there for you to consult. Overriding it to always return one value or another doesn't change any behavior, it just misreports to outsiders. The _selectionOrigin seems only to be modified via -setSelectedRanges... method if the selection is zero-length (ie, just cursor placement).
So, with all this in mind, you might have to add one step to your manual selection modification: First set an empty selection with a location where you'd like the selection origin to be (forward end if you want backward affinity; backward end if you want forward affinity), then set a non-zero-length selection with the desired affinity.
Roundabout and ridiculous, I know, but I think that's how it has to be, given the CocoaTron source code.
We have a script that export our Indesign documents to HTML and one of the routine is to export tables. In this script we go throught each Tables->Rows->Cells and evaluate some of the properties (i.e. bottomEdgeStrokeType, topEdgeStrokeType, etc...) and transport them to HTML.
Now yesterday we had problem converting one particular document because some cells were missing the "bottomEdgeStrokeType" property entirely. I've discovered this by outputting the properties of each cells and compare the faulty ones with the others.
This line bellow was trowing the error: "Invalid object for this request.".
var cellType = cell["bottomEdgeStrokeType"];
Now, to fix this I've wrapped this around a try catch block to handle the case when it's not there, but now what is puzzling me is how on earth can Extendscript instantiate an object with missing properties?
Indesign version: CS5.5
A property is not only 'undefined' if it cannot exist at all (such as asking for the parent text frame for a character in overset text), but InDesign's Javascript engine also fails to return a reasonably accurate result for multiple values.
If you ask for "the" point size of a paragraph, where this paragraph contains multiple sizes, poor ID does not consider to return something like CONSTANT.Mixed, or the first value only, or (what I might have preferred) an array of the values; it returns undefined instead.
So how can a single table cell have multiple bottom strokes? If the cell underneath it is split into multiple cells, and one has a "top" stroke but the other has not.
It's difficult to recommend an adequate solution. You could first test if the current cell is "merged" (as far as InDesign's internal table model is concerned) with columnSpan; and if so, iterate over the number of columns spanned and test the next row's cells for their top stroke, which in theory should match the bottom stroke of the cell above. (I find myself wondering if this is always true. ID's table model is ... weird. It's not entirely like a HTML table, despite the functional overlaps.)
If columnSpan is greater than 1 and equal to the number of cells immediately below the current one, you could test if all of their "top" values are the same and if so use that value. (I never tested this so ID's table model may simply fail because a cell is merged, regardless of same-values or not.)
One could attempt to flag this cell's next row to output "top" strokes as well -- but alternating top and bottom strokes may not align nicely in CSS, side to side. Perhaps it's best to translate only the first top stroke value to "the" bottom stroke property for your current cell, and fix up manually where needed (how?) or, a reasonable action, hope that no-one will ever notice it.
Is it possible to subclass or similar IUP controls to get modification in functionality on lower level so changes can apply to whole project (all instances of controls).
1)
For example, in my locale we don't have decimal point but decimal coma sign on numeric keyboard. It would be ideally that IUP spin accepts coma and point for decimal point.
Can that be done and how?
2)
How to get parallel navigation with keyboard (Up/Down) on IUP dialogs like we have tab/shift+tab.
3)
How to get value on input controls to be selected when get focus?
4)
How to recognize mouse doubleclick on IUP matrix cell?
Sorry for mixed questions but I need those answers now.
Thanks.
Yes, it is possible to subclass. But it is is very low level and requires to download IUP source code. The documentation already includes information about the internal SDK. It is easier to simply create a function, for example myIupLabel() that creates a IupLabel and sets some pre-defined attributes that will be used by the application.
1) As far as I know there is no control of the decimal point in IUP spin. You have to detail more what you are using. If it is the IupSpin control, if it is a IupText control with a SPIN attribute, and if you are using the MASK attribute of a IupText. And Yes, it is possible so solve that problem, but how depends on these details.
2) This is already done for toggles and buttons.
3) You mean IupText controls? Use the GETFOCUS_CB callback and set the SELECTION attribute inside the callback.
4) The double click is used for editing. The EDITION_CB is called when a double click occur. But there is another way. You can set the BUTTON_CB callback since the IupMatrix inhertis from IupCanvas, but you will have to save the previous one and call it from inside yours.
It appears there is no way to style individual cells (to, say, change the background color of a header row, for example) within a GAS FlexTable. Is that correct?
The only methods I see here are .setStyleAttribute() and .setStyleAttributes() both of which operate on either the entire application or the entire flextable as the object.
Furthermore, I see no methods that return an individual cell or subset of cells from the flextable such as a .getCell() or .getRow().
Therefore, am I correct in concluding that there is no way at this time to set the style of an individual cell in a GAS flextable? (Sorry if the answer to this question is an obvious, “There is no way to do it.” But I figured I had better check with the experts first before giving up.)
setWidget is expensive
I pull out about 500X12 table in flextable and found use setText is at least twice times faster.
Then again, I also can not figure out how to change font size in flexTable while calling setText. The background, font color etc worked, but not font size.
Setting style to individual cell is done with:
method setStyleAttribute(row, column, attribute, value) - Sets a CSS style on a cell of this FlexTable.
You have to scroll down to the second occurence of setStyleAttribute on the FlexTable page. Since the HTML anchor is #setStyleAttribute for both methods you always get the first.
A getCell method would not be useful as a flextable cell is no widget.
There is also a setStyleAttributes(row, column, attributes) method ...
There is a very easy way to do this. Instead of using FlexTable.setText() to set the contents, use the FlexTable.setWidget() instead.
And you can add a label and style it however you want to and each label can have its own style
Let's say I have a Size class which has height and width properties (in reality the class is a bit more complex than this, but Size makes a good example).
I want to display this as $width x $height in my UI.
The obvious way to do this is to bind to a dimensions property which is dependent on width and height.
My question is where is the best place to add this new property?
I could add it to the Size class itself in the modal, but then if another controller wants to display the string different I'm stuck creating yet another property. I'm also a bit reluctant to do this because in my case the Size class is in a framework that will be used in a couple different places (although likely all from code I have control over).
I could add it in a category to the Size class inside the project containing the view/controller so it will only be availiable in the places I know it will be used, but in various places I've seen suggestions that categories tend to be overused, and am forced to wonder if this is one of those cases.
In the case of a single Size instance I could create the property in the controller class containing it, but this becomes more difficult when you have an array of Sizes.
I could bind to the entire size object and use a transformer to turn them into strings, but binding to an array of sizes would then cause you to have to transform each element of the array into a new array in the transformer, which seems a bit ugly.
If want to display this composite value as a string, then bind "Display Pattern 1" of a text field to the width property and "Display Pattern 2" (shown when you bind Display Pattern 1) to the height property. In the Display Pattern 1 binding, set the "Display Pattern" to %{value1}# x %{value2}# (yes, slightly unintuitive syntax). This will give a text field that displays "[width] x [height]" and will update on changes in either property.
You can do the same with an NSTextFieldCell, e.g. as the cell in an NSTableColumn. The downside of this method is that the text field will not be able to edit the bound width and height values. You would have to write an NSValueTransformer if you need to be able to edit them.
Using multiple bindings through a display pattern as Barry suggested sounds like the best approach, at least without knowing more about your UI. I've used the same thing in the past, where I built an inspector for an array of images and had the dimensions bound to a single text field.
In general it's good practice to use value transformers or formatters if you can, but in cases of last resort there's nothing wrong with using a category. I've done this in the past when I had trouble binding to a date, but breaking it down into individual time and date pieces. A category is a good approach because it lets you maintain separation with the model, but you don't need to do anything crazy like binding directly to the controller.
I want to display this as $width x $height in my UI.
Why not two fields? Then you could make them editable.
(in reality the class is a bit more complex than this, but Size makes a good example)
Assuming the above is not feasible in your real situation, you might try creating a custom subclass of NSFormatter, and setting it as the formatter on the cell (I assume this is in a table view, since you wouldn't bind a single control to an array). You would then bind to whole Size objects.