Competent VB6 developer required to modify an existing commercial desktop application to run well under Microsoft Vista. In addition to VB6, experience of manipulating MP3 and WAV file formats would be a big bonus, but is not essential. Familiarity with php would also be helpful but is not essential. You will need to be comfortable using Win32 API calls to interface with Windows and to perform HTTP transfers.
The application uses various 3rd party COM controls to record, manipulate and merge sound files, and to write them to CD.
The tasks involved are primarily to ensure the application saves datafiles in the correct folder structure (i.e. under Documents, rather than Program Files) and to resolve any issues around security privileges. As such you will need a Vista development environment, and ideally Windows XP and Windows 9x for regression testing and support purposes.
The application is reasonably compact, involving about 10 functionally-rich forms; however it has been modified by a number of developers and the code lacks a single clear style or structure.
You can download a demo version of our existing software at:
<[url removed, login to view]>
You will be provided with all of the existing source code you have been choosen.
Here is some information that was written by our previous developer to assist in understanding the current version.
VisionGuider is a VB6 standalone desktop application for the recording, merging and saving of sound files.
To manipulate sound files, VG relies on a number of 3rd party add-in components, to:
Record sound files
Convert sound files from WAV to MP3 format and vice-versa
Merge sound files together
Play back sound files
Provide information about CD writer hardware
Manage burning of files to CD
The application is implemented via a range of forms, each defined as “dialog?? forms (i.e. non-resizeable) and displayed modally over the top of each other. (There are some exceptions to this, such as the form used to host the “burn my CD?? web form). The user interface uses custom graphic objects in place of standard buttons (at the client’s request). These buttons mimic typical Windows XP appearance, but of course whilst creating a fresh new look when originally developed, these will look a little outdated under Vista. There is code involved with each button to set a red graphic behind the button, and just a little larger, to create a (fairly crude) red highlight around buttons at mouseover. It may be appropriate to review the use of these buttons and replace with a separate custom control at this point, simplifying maintenance and ensuring a consistency of interface. One of the problems with the current buttons is that the texts have to be created in a graphics program such as MSPaint, and the original fonts used are unknown. Therefore when any button’s caption changes, I’ve had to copy/paste letters from other button faces to build up the new caption; a tedious and time-consuming task, and one that results in not very high-quality buttons anyway.
For file management tasks (i.e. File Open and File Save dialogs) I have used direct calls to [url removed, login to view] (using common code in the modMain module) rather than using the [url removed, login to view] wrappers, which can be the source of version compatibility issues.
Registry access is via a fairly complex set of routines within modReg32; these were “inherited?? from the original developer. They work well under Win9x, Win2K and WinXP, but there may be security issues under Vista. In any case the registry keys used will require changing (see below), although this must be done in such a way as to preserve user’s existing settings.
In addition to local operations, a number of features require communication over the internet with GotVision’s web server:
Verification of registration information
Listing and downloading of music library data
Display of “burn my cd?? web forms
Upload of data for burning to CD by GotVision
Registration information is held within the Windows registry; this was originally (incorrectly) stored into the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\GV key, where for backwards compatibility with earlier releases it has remained. This may not be acceptable under Windows Vista for security reasons, however. The key items written to the registry are the username and pwd (password) fields (both text). When a user starts VisionGuider, the application checks to see if this data is present in the registry. If it is, the assumption is made that the data is valid, and no further check occurs at startup; hence startup does not require an internet connection. If no registry information is found, the user may continue in “demo?? mode (restricted functionality), or they may enter a username / password combination (these will have been set during online purchase of a license at the GotVision website). On receipt of this data, the application invokes an HTTP request to the GotVision site, passing the username and password, and receiving a yes/no response; if affirmative, the registration information is stored in the registry and the application continues in “registered?? mode. If negative, an exception message is displayed and the user invited to re-enter their credentials.
Should the user attempt to access the GotVision music library (website), their credentials (if present) are re-validated to ensure that they have a current license to use the website. (Registrations for the software itself are open-ended; however a license to use the music library may expire; the validation process returns a failed validation should this be the case. Note that if the user is in “demo?? mode (with no userID present), they get automatic access to the library, via the reserved and non-expiring userID “testuser?? and password “letmein??; these values are hard-coded in the application.
The library listing is a simple php-generated webpage, hosted within a WebBrowser control within the VB6 application. Note that the Microsoft component “WBCustomizer?? is used to suppress context menus and other functionality of the web browser control. (WBCustomizer is freely downloadable from the Microsoft site, and included in both the setup and the source for Vision Guider; simply register it using [url removed, login to view]).? WBCustomizer is also used on the web browser control that hosts the “burn my cd?? form.
An additional task that occurs at application startup is a check of the registry for any pending file upload to GotVision. If the user has no CD writing hardware, they may choose GV’s burning service, by completing a (hosted) web form within VisionGuider, and uploading their files to the GV server. Since these files are typically extremely large (dozens or hundreds of megabytes), there is a risk of interruption and failure during upload. When the upload process is started, information is written to the registry about the files to be uploaded, and the form information is also saved. As each file is successfully uploaded it’s data is deleted from the registry. At startup, therefore, the presence of any such track upload data in the registry indicates a previous upload failure, and the application prompts the user to confirm that it should restart.
The upload itself is performed by a separate standalone executable, GVUpload, that is launched from code within Vision Guider. This little program uses the same public-domain VB6 code as the main application to perform FTP transfer up to the server. The uploader looks in the /combined folder under the application folder to find the files for upload; however for compatibility with Windows Vista, the application data files should be held within the user’s Documents folder structure, so this small tool will require some code changes. Note that the FTP code, inherited from the original developer, is a little “OTT?? and makes use of the colItem and clsItem classes, which are otherwise unused. VisionGuider uses the FTP components to check for files on the server, and to delete them, prior to performing an upload of merged sound files for CD burning.
For checking user credentials and for downloading song data from the library, low-level HTTP functions are used, calling [url removed, login to view] directly. Although relatively complex, this approach seems reliable enough, and has the advantage over the much simpler XMLHTTP approach of being able to provide feedback about progress during download of a large file. For this reason alone it’s probably worth leaving in place; that said there have been some user reports that they cannot connect to the library for song download, despite having previously registered successfully. Such error reports are inevitably very complex to resolve, since they involve so many variables, and with so little diagnostics to help.
The most troublesome areas of code over the past couple of years have been around the recording of voice data, and the actual mixing of voice and music files. When recording voice data, the user has the option to pause and continue, or to “rewind?? and continue recording from a certain point. The tool used to manage the recording is an asynchronous component that fires events each time the “play position?? of the recording playback changes. Unfortunately this event only fires when the position changes by 1% or more, which is fine for short recordings but for lengthy recordings 1% can equate to several seconds. Thus some additional code is needed to determine the actual playback / record position to 1/1000 of a second; this is needed to determine accurately when playback has actually completed, and for various other functions. After the most recent changes, the current code appears to be robust and accurate.
At mixing time, the difficulty appears to be in setting appropriate volume levels. The actual mixing is simple, essentially a single method call once the control’s properties have been set. However music recordings tend to be at a much higher level than voice recordings (due in part to the nature of desktop and headset microphones often used by VG users), whilst we generally want the music to be playing softly in the background. The mechanism used by the control to adjust volume is a fairly crude affair allowing effectively a percentage increase or decrease in volume; however there is no measure of absolute volume peaks of the recorded sound, so balance tends to be a trial-and-error affair. The user controls increment or decrement the volume settings and cause a re-mix; the application can be fine-tuned by adjusting these percentage increase/decreases, and the initial settings at first mix time.
Mixing (and format conversion) takes place using temporary files; these are allocated to the user’s temp folder using system calls to determine the correct location, and this should be valid under Windows Vista. Bear in mind that the code will require changes, however, since the original location of the input files, and the final destination for the output file, will need moving to be within the user’s Documents folder structure.
The VG installer is created using the freeware tool Inno Setup (see <[url removed, login to view]> for download details). This is a simple but powerful tool that uses a single .iss file to define the files, folders, options etc for the installer. Note that as part of the install, the sample voice files are actually installed as .mp3 files, then converted to .wav file format. This one-off conversion is performed by a separate executable, [url removed, login to view] (again the source for this is provided). Note that since this loads the .mp3 file, and saves the .wav file, to the application folder this tool will require modification for “silent?? running under Windows Vista, in order to access files within the user’s Documents folder structure rather than the Program Files location currently used. The installer script itself will also need changing for the same reasons.