Weird StackTrace behaviour

A colleague noticed that changing a combobox wasn’t showing the changes in the text fields below.
When testing, I saw it WAS working. But with the click-once application not.
After some time I noticed running the release without visual studio, it didn’t work.
Although it worked when running with visual studio. Also the debug version was working.

For binding the text fields to my object I simply used a property: “Regime”.
The (work)regime has 10 properties: id, user(id), “Monday” till “Sunday” and “weektotal”.
All these properties raise an event by calling “PropChanged()”.
This method would look up into the call stack which method called him. Properties get set_ and get_ before the property-name as method.
This way I could test it was ending with “day” and then also raise a “weektotal”-changed event, as this property is read-only and actually a property for binding the total of all days.

Private Sub PropChanged()
    'Get the stacktrace and get the calling method
    Dim stack As Diagnostics.StackTrace = New System.Diagnostics.StackTrace
    Dim method As Reflection.MethodBase = stack.GetFrame(1).GetMethod()
    'Methods starting with "set_" are the properties
    If method.Name.ToLower.StartsWith("set_") Then
        'remove the "set_" and raise the event with the propertyname
        RaiseEvent PropertyChanged(Me, New PropertyChangedEventArgs(method.Name.Substring(4)))
        'when the day changes, the total is also changed
        If method.Name.EndsWith("day") Then
            RaiseEvent PropertyChanged(Me, New PropertyChangedEventArgs("weektotal"))
        End If
    End If
End Sub

In a combobox I had a list of “presets” and when I select one, I update the “Regime”, to have the same values. Now, this wasn’t working.
After like testing everything, for fun I showed a messagebox with the method.Name property.
This let only see: “.createWorkRegime”, a complete surprise as it was actualy called by the Property “Monday” or “Tuesday” etc.

Obvious, when adding the plain RaiseEvent PropertyChanged, the binding works.
I didn’t figured out why this happens, but it looks like the call-stack is changed when using properties in the constructor.
I really don’t understand it as it’s only having this behaviour when used in the constructor.

So it is changing the call stack AND ONLY when its executed from release (and directly the exe and not by visual studio)

If someone knows why this is happening, please let me know.

Java MD5 (hex)

I needed to make a program in java which logins with the vBulletin login system.
As you may know, many php boards use MD5 for hashing passwords.
vBulletin uses a “more advanced way” of hashing, just like phpBB3. phpBB2 used just old plain MD5 hashes.
So I needed to find out how I could use MD5 in java.

Off course there is no MD5 function like in php .
That’s why I searched a function that can do it, a little search on google like “java MD5 function” and so I looked at the first pages links and tried the functions that weren’t too long.


I created the vBulletin login system in java and with the first test account I could login …. BUT my own login failed :(. Quite irritating if you try 10 passes, all work and when you put it live, many people complaining they can’t login…

As I got “lucky” with my pass, I found that my hashed login was wrong, so after some debugging I found a 0 (zero) was missing in the first MD5. So the MD5 function was WRONG:(

As a test, I created a program that creates random passwords and create the MD5 of it with the functions I found on different sites (found by using  google).

Extra info

Both MySQL and php’s MD5 function has a hex notation, clearly not all MD5-functions found are hex notated, this is not a must, but off course needed for being compatible with php/MySQL.

The problem

In the next image you can see the standard behavior of the MD5-function found.
Most of them looks okay, but notice that the one from bombaydigital uses upper-case hex notation, and by using it for another round with MD5 it will go wrong.
The one found on Stockoverflow clearly doesn’t use hex-notation. And the one from Spiration, lost a 0 (zero).

MD5 function output from different sites

With double MD5 you see the differences even faster, like shown in the next image:

differences seen by using double use of MD5 functions found for java

The first marked line, you see that Spiration’s MD5 is wrong, in the second marked line, you see Spirition’s MD5 is ok. So it’s not reliable.
In the first and second marked lines you can see that dzone’s MD5  is ok, but the third and fourth are wrong. Also, not reliable.
As noted by single MD5, StockOverflow is not hex and bombaydigital is upper-case, so both functions aren’t giving me the expected output.

The right solution

This leaves us with the one from twmacinta, clearly it’s working, but in code, I needed 779 lines (including comment)
But it’s not really worth if it can be done in nearly 10 lines of code.

public String MD5(String md5) {
   try { md ="MD5");
        byte[] array = md.digest(md5.getBytes());
        StringBuffer sb = new StringBuffer();
        for (int i = 0; i < array.length; ++i) {
          sb.append(Integer.toHexString((array[i] & 0xFF) | 0x100).substring(1,3));
        return sb.toString();
    } catch ( e) {
    return ';

So don’t just copy/paste everything you find by using google. Other sites (just like me) can be wrong, yes, we are also just people.