v0.9.3, Come and Get It!

Download (Tested on Windows XP/Vista/7)
Wall Flype v0.9.3

 Wall Flype seems to be functioning quite well (for me at least).  So, I think it is time for it to grow some wings and get out there.  I am sure that someone will make it do something funky and that is what testing is for to work the kinks out before a large release.  To bring this version about I have selected 6 images from Chris Gin's gallery and set up a contributions window under the help menu that attributes Chris for his contribution and have put up a link to his site.  I have also attributed the contribution of the icon Wall Flype uses to Paul Davey that he has released for use under a Creative Commons license.  There is also now an about window that details the version of Wall Flype curretly installed and other information.  An important feature, an email link to wallflypedev@gmail.com has been set to the "Report Bug/Suggestion" menu item under help to allow users to submit bug reports and suggest feature to add to Wall Flype.

I intend to add a user manual with my next release to aid users with the usage of Wall Flype.  For now, please direct all your questions to wallflypedev@gmail.com.

 

Wall Flype v0.9.3 running on Windows 7

A Simpler Time

After overcoming the shortcomings of the Timers::Timer object and its non-exposure of the remaining interval, I have run into a new annoying point with using WinForms.  So, my task is to simply ensure that only one instance of Wall Flype is allowed to run at any one time.  In Win32 programming the main function provided a lovely parameter hprevInstance, which held a handle to a running instance of the application.  This parameter could easily be checked against the hInstance parameter to ensure that the system did not have two instances of the application running.  This is no longer the case with WinForms.  I had to use a Mutex to disallow the second instance usage of the code that allows it to start.  This was simple to implement, but I am still perplexed about restoring the main instance from a minimized state.  Doing a bit of searching I came across a native function from the user32.dll, ShowWindow that is supposed to change the windows state.  So far it has failed to do its job.

Regardless of being able to restore the main instance window from the minimized state, I have suppressed attempts to run a second instance of the application which was my main goal.  Aside from this work I have found an icon to replace the default and I have selected 6 images (1680x1050 resolution) from Chris Gin's gallery on InterfaceLIFT.com.  I set up the images to install under the application directory with the path AppDir\Wallpaper\Chris_Gin.  I will give other images I include in the pack a similar path.  The next release is almost here! :D

A busy day for Wall Flype (and me)

Well, there have been two firsts today.  I released the first version of Wall Flype and I have received my first response from the inquiries I have made to photographers asking to use some of their images to pack with the Wall Flype installation.  Chris Gin, a photographer who's work I discovered on InterfaceLIFT.com, has replied allowing me to use up to six if his images.  This is very exciting as his photography is high-res greatness!  My arduous task will be selecting only six images out of his library of amazing photos.  So, I want to thank Chris for being the first to reply and for allowing me to package some of his images with Wall Flype.  My baby (Wall Flype) is really growing up quick LOL! :-D

v0.9.1, Platform testing

I have been successful with installing and running Wall Flype on Windows XP, Vista, and 7.  On Vista and 7 ran great except for one little hiccup.  Upon the first load of Wall Flype on any system it selects the current user's picture folder to be the source folder by default.  This is fine on XP because the permissions are not as strict as they are on Vista and 7, but because of the latter two being more security minded strict permissions are involved with user accounts right out of the box.  When Wall Flype attempts to use said folder the program fires an unhandled exception.

The fact that this is cause by the permissions security is purely speculation as of this moment.  However, this is my hypothesis because of the exception information and the fact that if unloaded and reloaded Wall Flype will function perfectly.  So, if you are running Windows Vista or 7 and you receive an error on the first loading of Wall Flype, simply shut it down by clicking on the X button in the top right-hand corner and reload it.  I will have this fixed by the next release as it is first on my list.

[Update: 2/24/2010] In my ignorance I jumped to an erroneous assumption about why I was receiving an error on Vista and 7 platforms.  It turns out I was trying to access a directory path that does not exist and that was the cause for the error.  I had set up the default path for the source folder to be the current user's picture folder.  So, on WindowsXP that path would be "C:\Documents and Settings\[UserName]\My Documents\My Pictures".  I used a literal string for the last part of the path: "My Documents\My Pictures" and this was the root of the mistake because the path to a user's default picture folder on Vista and 7 are different e.g. "C:\Users\[UserName]\Pictures".  This has been rectified by making the default source folder path the relative path of the wallpapers packaged with the installation.

Download Wall Flype v0.9.0

Download
Wall Flype v0.9.0

This is the first release of Wall Flype and until it reaches version 1.0.0 it will be in a testing/suggestion phase.  I have created an email address to allow users to reach me with bug reports and suggestions about features in Wall Flype.  That email address is wallflypedev@gmail.com.  I will integrate this into the program with the next update that I release that way users will not have to remember the email, the program will open an email response window for them.  I am excited about the first release so even if you don't have a bug to report or suggestion please email me with comments about how you like Wall Flype.  I am thinking about creating a FaceBook page dedicated to Wall Flype as well...  Happy Wallpapering! :-)

v0.9.0, ready for distribution to test group

I have reached a point in the development of Wall Flype that I believe it is ready for its release to be tested and for suggestions to made by users.  I have implemented all the features listed thus far in this blog's first post.  I will add more features as the application grows with the suggestions I receive from users.  Before I release to users that I cannot get into direct contact with I will have to determine a solution to use for reporting errors and making suggestions.  I will likely create an email dedicated to receiving these messages.

I have finished the setup and installation program to install the application and am going to distribute it to a couple friends.  One concern I have right now will be the application running correctly on the newer versions of Windows.  I have not tested Wall Flype on any platform but Windows XP thus far.  I don't believe there will be a problem with Vista, but Windows 7 I am unsure of because of the way in which it changes its desktop wallpaper.  As long as Vista and 7 still use the SystemParametersInfo function from the user32 library to update the desktop wallpaper the application will work fine.

Onto a legal note, I want to compile a few nice wallpapers to give start to a user's wallpaper library.  I have a site I use for my own wallpaper, but if I am going to be distributing these images I want to ensure I have the right to do so.  This means I have to check the license that is bound to the image by the site.  I may have to contact the owner of the images to use them.  I will likely do so regardless of the license and offer them to test Wall Flype.

v0.8.7, A simple time issue

So, in my last post I talked about how the interval would be saved and two potential behaviors for how the interval was going to read back into the program upon reloading. Well, what seemed to be easily implemented in theory turned out to be a rather arduous task indeed. Instead of the System.Timers.Timer object exposing a property to get the time remaining until an Elapse event occured, I had to use a complete work around by using a DateTime object instance to get the interval when it is set and determine the time it has been running if the program is stopped between the timer restarting and the Elapse event firing.

I got all the kinks worked out of this part and ran into a bit of trouble when attempting to save the value of the time left until the Elapse event to the registry.  I am saving the interval and the actual time left to elapse in milliseconds.  Well, I didn't take into account that saving these values as a DWORD type would cause the values to exceed the max value of the DWORD type.  To repair this I changed the variables from a UInt32 type to a Double type, which is capable of holding a much larger numerical value.  I then saved these values as a QWORD type in the registry.