2011. július 13., szerda

Switch to new blog-site

Blogger / Blogspot / Google Blogger, what ever you call it, this blog is powered by it. I don't like it. I felt it for a while, and now I determined to switch.

I didn't post for about 6 months, that's because we're working on our Startup project. Now it gets closer to the first public release, so I made some revision. Part of it is I switch to Tumblr from here.

Also I split my blog into 2 parts:
My new life and IT related blog is here: http://shadevampire.tumblr.com/
And a development related is here: http://shadedevelop.tumblr.com/

So this is the last post here. I like cleaning old stuff. I feel it will be better. Refresh your RSS if you want to follow.

2011. január 14., péntek

Shade Simples

I was running through my computer's hard-drive and I found some precious projects I've written, and I decided I will share them with their source-code as well. I picked Sourceforge, my favorite open-source site, made some revision on them and pushed the ones I found useful.

Some of them already listed in Softpedia (without the source-code): http://www.softpedia.com/developer/Viktor-Benei-74740.html

Feel free to check them out.

Ohh, I almost forget: the sourceforge project, in which I manage them (with descriptions, licence conditions, etc.): https://sourceforge.net/p/shadesimples/home/

2010. december 2., csütörtök

Handy Visual Studio (well, not only) features (#warning and #error)

These messages to the compiler can be processed by other IDE-s, but I only tested them in VS (Visual Studio). They work in C++ and in C# as well under Visual Studio.

Quick syntax:
#warning "My warning message" // it's supported by most of the common compilers, but Visual Studio doesn't support it under C++, but it does under C# - in C++ (in Visual Studio) you should use the below mentioned #pragma message("...")
#error "The reason of the own compiler error"
#pragma message("My warning message")

So, why are #warning and #error interesting? Simple: #warning is very useful to make TODO list right in code, and #error is great for... well, for own compile time errors.

Example for #warning where I use it: sometimes I write the call for a specific method before I actually write it. For example: in the constructor I call the this.initialize() method, which is not in the code at this time, but VS allows the function template generation with clicking to the uncoded method's name (this time to initialize()) and choose from the popup menu the Generate method... item (or a faster way - select the method name and press Shift + Alt + 10).

This way VS generates a template like:

private void initialize()
            throw new NotImplementedException();

But if you don't implement this and you forget it you won't be warned at compile time, only at running, and only when the method actually get called. So a better solution is to add a #warning to this method:

private void initialize()
#warning "Implement this"
            throw new NotImplementedException();

This way you will get a compile time warning as well!

The second usage (which I use more frequently) is make todo-s to yourself, like:
#warning "TODO: this method is not efficient enough, it's only good while testing."

A simple example for #error (from the below referenced stackoverflow topic):

#if !defined(FOO) && !defined(BAR)
#  error "you have neither foo nor bar set up"

These (#warning and #error) are great utilities which are provides huge freedom to how and where you use them.
You use one of them (or both) frequently and find them useful at daily routine? You're free to share how you do it (via comments) :)

:: More informations and references

From the lovely stackoverflow (actually this site is one of the best programming related forums): http://stackoverflow.com/questions/2143352/add-my-own-compiler-warning - here's a little quote:
"Although there is no standard #warning directice, many compilers (including GCC, VC, Intels and Apples), support #warning message."

And a link to a support.microsoft.com page describes the #warning directive ("How to use the #pragma message to generate user-defined warning messages in Visual C++")http://support.microsoft.com/kb/155196

2010. november 12., péntek

Class decomposition with (partial) delegates

First of all: never hack any part of the your code! I mean: there's a feature you have to make it work, and you see 2 different solutions: "I could rethink this part of the code, make some refactoring, some interface / relation changes, but I could do this feature with changing 3 functions as well. They won't do exactly the same as they did, but it's so much less work".

Don't do this!!!

Even if it works as you expected it can break other part's behaviour. And mostly it won't work as you planned, and you have to hack other part of your code as well. Additionally, when you working on something huge (long term program) it probably will break other funcionality of the program which you don't recognize at that time but after some weeks / months later.

I know working against deadlines makes this decision very hard, but you have to make the right decision and rethink what you'll implement, it will make your life much easier at longterm.

So, class decomposition. When you're working on a project for a long time (years) you'll very likely hack some classes as I explained above, mostly because of deadlines. I just recognized few of my classes looks exactly as I mentioned - it contains a lot of different type of behaviors which could be separated. One of them has about 50 methods, and after a short thinking I figured out I could break them to 4 parts. Great! But I have a deadline again... How could I make classes like this much more cleaner and don't break interfaces (because that one would take really long time to refactor because the project already contains hundreds of files and classes)?

(My) Solution: (partial) delegates! (wiki: http://en.wikipedia.org/wiki/Delegation_pattern)
I left the original class to look exactly the same from outside, but I declared 4 delegates classes, each one is responsible for 1 type of behaviour.

The (object) communication: until now different classes communicated with the class (let's call it Gateway).

How does it works now? Simple: the classes communicates with the same class (Gateway), but it doesn't have the methods' implementation, rather it sends the message to one of it's delegates which will actually implement the method and possibly return some data which will be also returned by the Gateway to the original caller. (The delegates are classes, and the Gateway class makes one object from each delegate when the Gateway's constructor called, and deletes them when it's destructor called.)

Let's say Gateway is responsible for setting some global settings, and also it has to be respond to mouse events. Both part has some methods, the settings responsible for set the background color, or set an image to be background. And the mouse event handler part responsible for hangling mouse down, mouse move and mouse up events. Until now both parts happened in the Gateway class. Now, when a mouse event happens it will look for it's MouseEventDelegate (an object the Gateway class has), and it will send the same message to the delegate, let's say the mouse down event, but nothing more, it only passes it to the delegate. Then the MouseEventDelegate object will actually respond to this message and do some funcky things. Same happens to every mouse events. And when a global settings method called on the Gateway it will look for SettingsDelegate and pass the settings message to it, let's say set the background color to red. The SettingsDelegate object will perform the operation and returns to Gateway that it was successfully, then the Gateway will also return it was successfull to it's caller.

- It only works when you can separate different types of behaviours, as in the example the settings methods has nothing common with the mouse event handling.
- Sometimes they have some common / shared part, let's say in the MouseEventDelegate when it's mouse down method is called it has to set the background color to green. This time you can hold the background color in the Gateway class and pass it to the both MouseEventDelegate and to the SettingsDelegate class. This way both of them can change it. But you should avoid this every time you can. (In this case you could also make a new Settings singleton class which can be reached from both delegates).
- But: when the parts cannot be separated you have to look for another solution, because this kind of "extra parameter passing" when you use it frequent makes the code much uglier.

So this is not a "use it every time and everywhere" solution, but I found a few classes in my project which can be totally (or almost totally) separated, and the code looks much more cleaner than it did before. Additionally, when I got the time the code is already separated and can more easily refactor the whole Gateway class and tear out one of it's delegates. Actually if you can you have to do it immediatelly, but sometimes you don't have the time for refactoring tens or hundreds of files / classes which communicates with the Gateway class.

2010. október 24., vasárnap

The new Windows Live Mail 2011

In a few words: it's fantastic! I have to use it for some reason, and I  kinda liked it, of course I missed some features present in GMail, but I use it for different purposes.

Anyway, today I updated my whole Windows Live pack to the brand new 2011. The mail finally has the collect e-mails by thread function (which I really like in GMail), and it's design is simply beautiful! I watched some videos about the new Windows Phone 7, and I'm totally amazed with it's pure but still gorgeous design:

- and the Windows Live 2011 program pack has very similar animations and design (especially Window Live Messenger - now with Facebook integration, hurray! :) ). It looks great, and it works great.

A quick tip: it's hard to figure out how to minimize the Mail to the system tray instead of minimize it to task bar, but it's a must-have feature for lot of people including me. So here's the how to guide to reach this funcionality:

In Vista: simply run Window Live Mail and right-click on it's system tray icon (bottom right corner, near to the clock) - and it shows an option: Hide window when minimized. Left clik it and it works.

In Windows 7 (at least in 64 bit version I have) it's a bit more complicated. You have to open Windows Explorer (click My Computer) and navigate to: C:\Program Files (x86)\Windows Live\Mail (or to the folder you installed it, it's the default one). Here right-click on wlmail.exe and select Properties. In Compatibility tab set the Compatibility mode to Vista Service Pack 2. Now you can do the same as decribed above - run Window Live Mail, right-click it's system tray icon and select Hide window when minimized.

Shame on you Microsoft, you made a great program and missed to enable an important feature to get easily. But it works, and I forget this awkwardness, because I love the new design and how great it works.

2010. október 2., szombat

How to Synchronize your Google Gmail, Calendar and Contacts to your iOS device

Yes, you can synchronize these with the integrated iOS Mail, Contacts, Calendar. It's fantastic, works as it has to. The setting up is a bit complicated, but not too much - here's the detailed method from Google to the iOS devices: http://www.google.com/support/mobile/bin/answer.py?answer=138740&topic=14252
Read it and follow it carefully and strickly!

settings mail calendar contacts on iphone

2010. szeptember 4., szombat

Centerize Form or Window in the Screen at startup (C#)

It's easy as hell but not too intuitive - to the Form's constructor's top add:

this.StartPosition = FormStartPosition.CenterScreen;

This is it, it works. It can even centerize to the parent Form (replace CenterScreen to CenterParent).