Got another email reminder that Parse is shutting down. It’s quite disappointing that they’re shuttering this service after all the promotions and pushing it got – I used it for some ‘free’ logging on various apps but never really used it for anything serious. There always seemed to be a huge security gap – they gave you all these keys and secret keys to access your database, but they seemed to be pretty easy to find in an app, thus exposing the database to anyone who really wanted to see what was going on.
Can’t say I’ll miss them – though I’m sure there are others out there who are seriously annoyed by them going away.
I’m working on a custom editor extension that will support a palatalized color system for Unity3D UI elements (both NGUI and new Unity UI). As part of this process I’m learning how to create custom Inspectors and PropertyDrawers.
I added a struct to one of my objects that replaced a simple Int, and I needed to be able to access the struct from an inspector. Normally, to access the Int you’d create a SerializedProperty that would point to the public serialized int and then access the value with the .intValue property.
Once I updated the class to use a custom struct, the inspector no longer worked (obviously) and I needed to pull values from this struct instead of a primitive type.
The struct is defined as:
public struct PBMapperIndex
public int intValue;
public string indexName;
It contains a string and an int, and most importantly, it’s marked as serializable. This means Unity will keep the struct as a serializable object.
To access it in the custom inspector, I used the following:
SerializedProperty tintProp = serializedObject.FindProperty(“tintIndex“);
Where tinitIndex is declared as a public PBMapperIndex in my class.
Then to drill down and get the intValue for this property I used:
SerializedProperty ixProp = tintProp.FindPropertyRelative(“intValue“);
int index = ixProp.intValue;
Two keys, mark the original struct as [Serializable] and then used FindPropertyRelative to pull out the ‘child’ property.
I always love it when you think something should work one way and that’s exactly the way it works. Had that happen to me today with a Stack object.
I wanted to iterate over a List and remove any objects that are null. Now I know I can do a reverse iterate and remove any nulls as I come across them without breaking the List, but I wanted to try to do it differently, just because 😬.
As I iterated the List, I pushed the index of any entry that was null onto a Stack. Then when I was done, I could use Foreach on the Stack to pull out each index and remove it from the list. As I’d used a Stack, the entries are fetched in the order of last-in, first-out, even in a Foreach loop. Thought that might be the case, and was happy to find out it was.
Thought I’d share.
With my move today, I was getting all these funky Â characters all over the place. Always seemed to be just before a double space, so that lead me to believe that somehow the encoding was wrong.
Turns out the default config file has some encoding options turned on by default that was causing the problem. I was able to resolve it by commenting them out as follows:
/** Database Charset to use in creating database tables. */
/** The Database Collate type. Don’t change this if in doubt. */
Fixed all those funky Â that had suddenly appeared!
I migrated this WP installation today to a new server. The previous install was running on an AWS instance, and the configuration was setup to pull various files from /etc/wordpress. With this new configuration that was no longer possible.
I ended up using the sample-configuration file to re-create the config for this install & then updated the fields with the new DB details. Everything seemed to work like a charm!