You may have a favourite song want to share with your friends or customers etc on the internet. They can listen to the music in internet explorer or firefox without installing any music player.

MP3 Steam Creator is designed for such purpose. It creates streaming Flash audio from mp3 file on the fly. And it also supports batch converting a lot of music files.

The steps:

1. Download Mp3 stream creator. Install it

2. Add your mp3 or wav music files by clicking the “add file” button. Or you can do a search in windows explorer for *.mp3 and drag drop the files into the list box of Mp3 stream creator

3. In the option tab, you can select the play control style

4. Click “Convert” to do the conversion.

5. After conversion finished, for each mp3 file, there will be three files (Suppose the mp3 file is 1.mp3, the files are 1.swf, 1.swf.html, 1.swf.ctrl.html.

6. You can open 1.swf.ctrl.html in internet explorer to see the play control and try playing your music

7. If 6 works well, open your own webpage in a html editor, copy the content of 1.swf.ctrl.html and paste into a place in your webpage so that the play control can be embeded into your page

8. Finally upload the 1.swf and your modified own webpage to your web server

That is it. You now have a streaming audio player running.

Have questions? Feel free to comment.

The easiest way is to use our award-winning product htmlsnapshot.

Here are some guidelines:

 1. Download it and install. 
 2. Try the VB demo to make sure it works. Click the button to convert the url into image. This can tell you that the component is correctly installed. 
 3.  You can try the C# or VB.Net demo included. Open it with VS2003 or VS2005, build and run.
 4.  Another choice: you create a brand new C# project, add referrence to the htmlsnap2.dll.  Note, htmlsnapshot is an ActiveX control. So ususally it needs to be registered in the system’s OLE registry before using. You don’t need to do this manually if you install the component with our setup. If you want to deploy your application on a new machine, remember to register htmlsnap2.dll. Or you can use the regfree technology

Back to the topic of this post, how could you convert html to image such as jpeg, gif, png, tiff etc without generating temporary file? The code snippet is as below:

snap = new  CHtmlSnapClass ()               
snap.Url(“www.google.com”, “*”)
byte[] data = (byte[])snap.GetImageBytes(“.jpg”);
//byte[] data = (byte[])snap.GetThumbImageBytes(“.jpg”, 100, 100, 1);
//MessageBox.Show(data.Length.ToString());
FileStream  fs = File.OpenWrite(@”c:1.jpg”);      
BinaryWriter br = new BinaryWriter(fs);
br.Write(data);
br.Close();
fs.Close();

A new version of PDF split and merge is released.

This version fixed the crash problem in previous version. 

Thanks for the customer who reports the problem. It is always helpful to give us feedback so we can improve the quality of the product.

When you use html2image Linux on Linux OS, you can convert any URL into image.

But some times, you may need more advanced image processing features such as controlling the size of the image.

The solution is simple: you can use tools like ImageMagick or perl to easily resize the image to your size requirements after converting html to image with html2image linux.

The snap and processing tools can be glued together by linux shell script or any other scripting language like perl, php etc. 

Well, it is new year. A new release of htmlsnapshot product is updated.

DrawTxt method is added to allow user to add text watermark to the captured image.

I found a good guide article on MSDN today on this topic:

USER and GDI handles are sign extended 32b values To facilitate the porting, a decision has been made that these system handles should stay as 32b values, sign extended to 64b on the 64b platform. That is, the individual handle types are still based on the HANDLE type, which maps to void *, and so the size of the handle is the size of the pointer, i.e. 4 bytes on 32b and 8 bytes on 64b. However, the actual value of the handle on the 64b platform, (i.e. the meaningful bits), fits within the lower 32b, while the upper bits just carry the sign. This should make it easy to port the majority of the application code. Handling of the special values, like –1, should be fairly transparent. It also should agree nicely with all the cases where the handles had been remoted with the help of the IDL definitions from the public file wtypes.idl. However, care needs to be taken when remoting the handles was done via a DWORD, as the upper long should be properly sign extended on the 64b side. The app should use HandleToLong() and LongToHandle() macros (inline functions) to do the casting right. So, in general we can have the following situations: A handle like HWND, HMENU, HPALETTE, HBITMAP etc was sent as its own type (that is specified with HMENU, etc. as the type of the argument) – do nothing, ole32.dll code handles situation as appropriate A handle was sent as a DWORD – you can: leave it as such and cast the wire value to handle using LongToHandle() change the argument to long or LONG_PTR; this is possible in some cases only, When designing a new interface, in order of preference: use the types themselves, use context handles or use a LONG64 argument to hack through. Going back to specifics of porting the legacy code, the following system handles fall into the nice 32b compatible category. The USER handles: HWND, HMENU, HICON, HCURSOR, HDWP, HHOOK, HACCEL, HWINSTA, HDESK, HKL, HMONITOR, HWINEVENTHOOK. The GDI handles: HBITMAP, HPALETTE, HMETAFILE, HENHMETAFILE, HMETAFILEPICT, HBRUSH, HFONT, HDC, HRGN .

It is first day of 2007.

Wish all of us success and happy!