Is there an easy way for me to set a limit on the amount of characters my NSTextField can have? I don't want to have a counter then warn the user if it's over the limit, I want to set the limit so if it's past x characters that's it, they can't type anymore.
Check out NSFormatter. It can help you do what you're looking for and a lot more. If you don't need something that complicated, you might try the NSTextField delegate methods.
You could use Key-Value Validation to ensure the max. length is never exceeded.
This would allow you to additionaly notify the user if the entered length was too long - or you could just quietly modify the value.
Related
I'm using SortedSetScan to filter some data,my code is below:
db.SortedSetScan("SR.Cache.APP:Termial1", "A*", 50, CommandFlags.None);
but the pagesize is always not work,the result count always be all. What's wrong about my code? or is it a bug?
may anybody can help me,thx!
Yes, the result of that is always "all". The page size simply impacts the number of round-trips, versus the amount of data each call, when issuing the underlying ZSCAN command. The IEnumerable<T>, however, is lazy, etc, so if you only want the first 50 items, use:
db.SortedSetScan(...).Take(50)
instead, which will perform whatever operations it needs in order to get 50 items. Tweaking the page size simply changes how many operations are needed. It would be incorrect to think "I'll make the page size 50 so it only takes one operation" - it doesn't work like that; redis *SCAN commands can return empty pages, or pages with one or two items on, regardless of the page size. The page size is more a "how many things to look at before giving up for this iteration" guidance fore redis. This is described more fully on the redis SCAN documentation - in particular, read what it says about "The COUNT option".
Note that the sequence obtained from all of the SE.Redis scanning operations can be resumed at a later point by casting the IEnumerable<T> or IEnumerator<T> to an IScanningCursor, and obtaining the cursor details to supply as parameters.
You might also want to think whether the "range" methods are more appropriate (note: they don't allow pattern filters).
I have a system with lots of custom controls via V4L2 (exposure, gain, etc).. However, I need the ability for some of these controls (like a regularly repeated initialization sequence) to reset the current values of these without executing the s_ctrl callback.
I've noticed that sending an ioctl to set a value more than once to the same value, only results in a single actual call to the s_ctrl. However, I have some interconnected parameters that change these "under the covers" so I need to update the values so that a future value will be sent.
An example:
Disable autogain
Set gain to 100
Turn on autogain
gain moves around
Turn off autogain
Set gain to 100 <-- This one never happens, because it thinks the gain is still at 100 from before.
I finally found it...
You can directly set the ->cur.val property of the v4l2_ctrl entries to do this.
I received an abandoned student LabView project I need to adapt. There is one VI which contains an array of two controls with length 30. I need to change the strings in several places within that array which is possible as long as I do not close the vi. If I close and reload the vi the previous values are there again, saving the changed values as default does not help. Cutting the connection to the type def did not help either.
There is also no databinding and I could not find any mechanism that might lock the values. It must be something obvious to experienced LabView developers, but I could not find anything on the net.
What can be the reason that the values cannot be changed permanently?
Edit:
After playing around for a long time, i found out that I have to set as default value on the array, and not on the individual positions in the array. That solved it, simple problem, several hours spent...
After playing around for a long time, i found out that I have to set as default value on the array, and not on the individual positions in the array. That solved it, simple problem, several hours spent...
I want to display a very large text file but want to break it so that after every 1024 characters shown (page), the user will have to press next to read the next set of characters while back will take them to the exact same previous characters (if any).
Performance wise, am I to create an array of forms and store each 'page' or should the creation of the form be at the point the user presses next or previous?
Performance wise, none of approaches you consider is guaranteed to be problem-free. MIDP 2 specification (JSR-118) does not enforce any specific performance requirements for cases like that. As a result, different devices may behave differently.
To stay on a safe side, you may implement both approaches and let users choose which one works better on their device.
Another option worth considering is to use uneditable TextBox instead of Form. TextBox primary purpose is to display large chunks of text - because of that one may expect that sensible device manufacturers will provide an implementation optimized for that. TextBox even has a method getMaxSize which will let you know if device "thinks" that 1024 characters are too much for it.
Performance wise ?? That would depend on the size no short cut with j2me .... another option is to split the files to smaller chunks.
Reading InputStream ... Use read with offset and length is more efficient
InputStream is = getClass().getResourceAsStream(file);
is.read(b, 0, 1024);
You can add a comment of you need anything else
Thanks
:)
We have an NSTextView and some data saved about its contents in a core data Managed object context. Everything works great while the managed object context stays in memory. However when we save it, we get very weird fetch request behaviors.
For example, we run a fetch request that asks for all elements with a textLocation less than or equal to 15. The first object in the array we get back has a textLocation of 16.
I know I can't get a definitive answer here, as the code is fairly complex. But does anyone know what this issue smells of?
My thought is that we are somehow not getting the proper MOC synced with the NSTextView after saving? What could change that breaks this?
Thanks.
For example, we run a fetch request
that asks for all elements with a
textLocation less than or equal to 15.
The first object in the array we get
back has a textLocation of 16.
Really, the only way to get that is to (in reverse order of likelihood):
Mess up ethe definition of the attribute such that you think your are saving one type of numerical info but that you are actually saving another.
You've mangled the predicate so that it actually looks for values of 16 or greater. (You can test predicates against an array of dictionaries whose keys have the same names as you Core Data entities.)
It's an error in the conversion between a number and a string for purposes of displaying in the UI or logging.
I would start with (3) myself because it seems more common and until you confirm you don't have a display problem, you can't diagnose the other problems.
I finally managed to work out what was going on. I was setting textLocation using the setPrimitiveValue... just because I didn't want notifications to fire off. Turns out that's a really bad idea, because Core Data didn't know the value had changed. It still thought the value was 15 instead of 16.
Let this be a lesson: never bypass KVO unless you're INSIDE the managed object and you know what you're doing!