Okay, so, you just got handed a job for a 100+ page workbook. Your client wants you to fix some formatting or something of the like on every page (the 100 pages already exist… creating that many is a different story…). What do you do? You use macros and let the computer do all the work, silly! 😛 The best part is you can charge for all the hours it would have taken you to fix it all up without the snippet I’m about to give you! (Okay, this is probably a tad unethical…).
You’re interested? I thought so. We’re going to use the power of foreach loops to let the computer run through and do all this on every single page. The workflow I use looks something like this:
On the first page (or a “test” page), I hit Record Macro and name it something I can remember. Be sure that you remember what the exact name of it is. This is very important.
Proceed to style/do whatever it is that you’re being paid to do. Ahem.
Once you’re done, stop recording the macro. At this point, I usually like to test the macro before I use it on my entire workbook, just to make sure it isn’t going to destroy it all. 😛
If you have verified the integrity, now we need to write a bit of code. :O But I have never used the Visual Basic editor! Don’t worry–it’s incredibly simple and you can basically copy and paste this snippet I’m about to give you and just change one little bit for all your repeating macros.
If you aren’t familiar with Unity, it’s a free game engine with a built-in game editor. I use Unity almost every day, and as you can imagine, I’m coding a lot. Now, when you are writing the majority of code for a game, you are testing things out. Perhaps you want to see how fast is fast enough, or how far is far enough. It can be a pain to enter and exit play mode constantly, but wait!
Unity has a nifty little feature that will recompile code and execute it, even while in play mode. You can easily switch over to Visual Studio (or MonoDevelop) and save your changes. Then you can “Alt + Tab” back over into Unity and quickly see your changes. The only downside to this is that, with large projects (10,000+ lines of C#), this can take a few seconds–even on a really fast machine. However, it’s invaluable when testing things, as you never have to leave your spot in play mode. 😉
If you are still using Visual Studio 2010 (or older?), then you can just ignore this. Apparently, Microsoft’s UI design team decided to change the icons to a more “monochrome” color palette in VS 2012, so what you get is essentially gray icons for everything. These icons are a far cry from what we have come to know as save, open file, open folder, etc. However, I personally don’t really care to be honest, unlike most developers. If you seriously use Visual Studio 2012, then there is no reason you shouldn’t do these two things:
Learn those shortcuts! This is a must. Visual Studio has so many shortcuts that most actions take two keys plus a modifier! It sure beats having to look through context menus that are so big, they fill up more than 1,080 pixels vertically…
Customize the layout where everything is somewhere you can find immediately. Re-arrange the toolbars and memorize the icons’ respective locations. Even if you know all the shortcuts (unlikely), there are still some things I prefer doing with the mouse–namely opening files, as it’s easier to use the mouse to browse through the files.
If this still isn’t enough, there is always the NiceVS Visual Studio extension, which appears to bring back the colored icons so many people have come to miss so much. Use at your own risk, however, as I didn’t even bother to test this plugin. If Microsoft’s made a UI decision that coincides with the Metro UI (which everyone also seems to hate), it isn’t going away easily. There’s no sense in installing a plugin to try and undo what Microsoft has done, in my opinion.
Drag and drop is probably one of my favorite way of interacting with an interface. It’s just intuitive and works nicely. Implementing custom dragging and dropping events isn’t hard at all, as you can easily leverage the power of the Qt Event system with custom filters to customize behavior.
In this particular example, we’ll use a sub-classed version of a QPlainTextEdit and reimplement the Drop Event virtual protected method. If the user drags a text file on it, we want to open the file and output the text to the widget. Now, you could probably do this with a custom event filter, but this is a tutorial and really shouldn’t be taken literally for use. I’ll probably go over installing event filters another time, but sub-classing is an important skill to learn–especially in Qt for customizing behavior!
Before we get to the code, lets go over what happens. When you drag and drop something, several events are triggered. You can customize every aspect of it. For instance, when you are dragging a file over your application’s window, you could draw attention to the drop zone or something along those lines. However, we are mainly interested in the event when the user drops a file on our widget.
I’ve been working a lot in Unity lately, so I thought I should probably do a few tutorials on scripting in the game engine. One of the biggest helps I’ve gotten in scripting for the game engine (in which I use C#) is a nifty API function Unity provides that allows me to get all the objects with a specific type, i.e. game objects with a specific script attached. Since this is a quick tip, lets skip the behind-the-scenes and logic, and get to the code already!
MyScript myScriptObjects =
FindObjectsOfType(typeof(MyScript)) as MyScript;
This specific function returns a System.Object array of all the Game Objects which have the script MyScript applied. We then cast it so we can get a strongly typed array from the get-go. From here you can access each of these objects in a loop, store them in a generic, etc. Very useful indeed!
Basically the FindObjectsOfType is the same as FindObjectOfType, however, it is probably more useful in most cases I could see it being used since it works with array’s. A good use of this is to perhaps obtain values from each script and add them to a dictionary or list so you can use them, since performing operations en masse could be done just as easily with tags, etc.
So by now we have a complete application, but I’d like to pull out a few extra tricks. Primarily, I want to make the application store the state even if there isn’t any user interaction. This could be very useful if your application is a complex GUI comprised of several toolbars, etc. By implementing a continuous loop of state storage, even if your application crashes, the data will be preserved from a certain amount of time before. We’ll need to change a few things first, however, starting with the MainWindow declaration:
So you have finally got a decent-sized native project on your hands. You realize that your compile times are beginning to take so long you have to keep a video game on handy (Alt + Tab is your friend) while it builds, links, etc. When the finished compile pops up, you realize that you’ve left out a minus sign on line 529 of Math.cpp. Reluctantly you close the app that just took 30 seconds to pop up, and go into your IDE (If you have a project this big you better be using one), hit Ctrl + G and go to line 529.