Here is the same content in en-us.
This article may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist. To maintain the flow of the article, we've left these URLs in the text, but disabled the links.
|Using WinInet for File Transfer, MSDN Tree Control, The Web-safe Palette |
|Q To upload a file to a server from an HTML form you use this type of statement:|
I want to send a file to a server over HTTP in my C++ application. How can I do this?
<FORM ENCTYPE="multipart/form-data" ACTION="a.asp" METHOD="POST">
<INPUT TYPE="file" NAME="theFile">
A The use of file upload with an HTML form is not a very powerful method of transferring files. If you're writing a full-blown C++ application, you should take advantage of the rich networking interfaces supported by MicrosoftÂ® WindowsÂ®.
If you are writing a client-side application, I recommend that you use the WinInet functions (see http://msdn.microsoft.com/workshop/networking/wininet/reference/reference.asp). Specifically, you should use the FTP functions, since that's the proper way to transfer files between machines. You'll find some sample code that illustrates the use of FTP at http://support.microsoft.com/support/kb/articles/Q238/2/73.ASP.
If you really need to create a C++ application that behaves like an HTML form, you'll find Knowledge Base article Q165298 useful. It explains the use of WinInet in an MFC application to simulate form submissions.
Q I need to download a file using FTP once the file is created by another process. I will not know when the file will be created, but once it is I need to download the complete file. To check if it's complete, I currently download the file as soon as it appears and get its size. After one minute, I download the same file again and recheck the size. If it hasn't changed, I assume that the file is completely written out.
However, when I try to download the file the second time, I'm not seeing a new copy of the fileâ"I'm getting a copy from the cache, and obviously the size hasn't changed although the file is not finished. To solve this problem in Microsoft Internet Explorer, I chose the "every visit to the page" setting in Internet Options. Now I want to programmatically change this setting in the user's browser. How can I do this in Visual BasicÂ®?
A Programmatically changing the client's cache settings is almost certainly not the way to go. Web programmers should always consider client settings to be off-limits. This is exactly why there aren't any scriptable ways to access these settings. While it is possible to write an ActiveXÂ® control or plug-in that can dive down low enough to access such settings, they should be used only as a last resortâ"and often not even then. But since your real challenge is making sure a file is finished before downloading it, I have some suggestions.
Since the file was being transferred via FTP, the best solution is to use the WinInet API from within a Visual Basic-based application running on the client that performs. You can check http://msdn.microsoft.com/downloads/samples/internet/networking/vbftpjr/sample.asp for a sample application that illustrates the use of WinInet from within a Visual Basic-based application.
If you need a Web page to maintain some level of control over the processing, you could write an ActiveX control. Simply call into the control from script code to invoke the transfer, then check for the completion of the transfer.
If the FTP process must originate on the server, you could implement the server-side control from within your ASP code on the server. Note that WinInet is not optimized for server-side functionality, so you should only use this approach if you know that there won't be a heavy demand on the server.
By using WinInet and FTP, you will essentially bypass the cache, gaining greater control over the file download process. But since you also won't have to download the file twice just to verify the size, it really isn't an issue anyway.
Q In your March 2000 column you described the MSDNÂ® Online table of contents, which was created with Dynamic HTML (DHTML). If I remember correctly, it previously displayed a message that said it was powered by Visual J++Â®. Was it originally an applet? Is there a way to get the code? I'm considering using DHTML, but I want my table of contents to be cross-platform, so I might consider an applet.
A You remember correctly. The table of contents for the MSDN Online Library was a Java-language applet. There are many such tree controls floating about the Internet, hosting a variety of different features and capabilities. MSDN Online switched over to a DHTML version not only because it's faster, but because it's more flexible and has better cross-platform support. The MSDN folks are working on an article to describe how they used DHTML to develop their site, but the old Java-language applet will probably never be documented in this fashion.
Q I'm a professional Web developer trying to determine if I still need the Web-safe palette. I just read your MSDN Online article, "The Safety Palette", which you wrote in 1996. I have some questions about the underlying logic, and would like to know if anything has changed since the early days. In the reading I've done so far (on http://www.visibone.com and http://www.lynda.com), I've found a variety of explanations of the palette, including: Netscape picked these 216 colors when building its browser; these are the only colors that look exactly the same in GIF and system (code) hex on both the Macintosh and Windows; and these colors are evenly spaced intervals within the 256 cube (this from your MSDN Online article).
I don't understand why I can't pick any 256 out of the possible 16 million colors. Is the idea of the evenly spaced palette built into the technology? If I have 8-bit color support, can't I view any combination of any colors as long as they do not exceed 256 at any one time? And why are the 40 colors that are reserved for the operating system not among the ones you've selected for the safety palette? Is that just luck?
I've noticed that Netscape and Internet Explorer dither colors differently, and there are even differences between Internet Explorer 4.0 and Internet Explorer 5.0. In fact, I've gotten different results in every major browser and version. Another interesting note is that some browsers (Netscape 3.x, for example) dither non-Web-safe colors even when I'm running my display at 24-bit color. In addition, when displaying a non-Web-safe GIF abutted by non-Web-safe system color, Internet Explorer 4.0 and later render the colors continuously, even in 8-bit mode. To what extent does the browser limit the available colors and their rendering?
In particular I'd like to know what to do with 16-bit and 24-bit depth with Internet Explorer 4.0 and newer. Is there a new Web-safe palette for these? I suspect that any modifications to colors at this point would be too subtle for the eye to notice.
Following your own method for calculating the safety palette, in the case of 16- and 24-bit depths I get increments that don't seem so useful. On 24-bit the increment is 1, so that every color is included. On 16-bit, the increment is roughly 6.58, which yields a sequence of hex values that is definitely not as easy to remember as the 8-bit set. The 16-bit safe palette leaves off 1,536 colors. Also, the 16-bit palette does not include the old 8-bit Web-safe palette. But those should still be safe, right?
If I add the two palettes together, I get 64,216 colors, with 40 reserved for the OS, and 1,280 colors floating. What are those colors? In fact, what are the 40 colors that are not included in the 8-bit safe palette? What are their values and how do you know (since they're not following a simple pattern like the safe palette)?
Assuming this new 16-bit safe palette is correct and I can add in the old 8-bit safety palette, if I don't try to accommodate 8-bit clients, should I limit myself to these 64,216 colors, or should I just pick from the 24-bit palette because the alteration of color will be so slight? Or, should I pick any colors from the 24-bit palette as long as I don't try to display more than 16 bits worth of color at a time?
A Wow, that was a mouthful! Confusion about the Web-safe palette and about color in general is quite common, and misconceptions abound. In the interest of space, I'll address the salient points of your question and give an overview of the topic.
The most important thing to understand about Web colors is that there is no Web color consortium that dictates how browsers should implement color support. The actual algorithms are developed by the teams that write each browser.
When comparing the ways that browsers dither, it is extremely important that you are making the comparisons on systems that are set up identically. With the same browser, on the same computer, viewing the same image, you will notice dithering differences between 256-color, high-color (16-bit), and true-color (24-bit) settings. This is because while high-color has the potential to display over 32,000 different colors at the same time, the actual color resolution is not only lower than it is at 256 colors, but (almost) all of the colors are different as well. Thus, a color that you can request as a pure solid color on a 256-color palette-managed system may dither on a high-color system. The safety palette (see Figure 1) itself only comes into play on a 256-color system, since on non-palette-managed systems an attempt is made to simply display the color as is. So your query about what to do with 16-bit and 24-bit displays is essentially moot, since there is no notion of a non-dithering palette in these cases.
Figure 1 The Safety Palette
256-color Mode If a particular solid color is important in my images, I use one of the 216 colors from the safety palette because it won't dither on either a 256-color display or a 24-bit display. However, it may dither on a 16-bit display, but the dithering will be almost unnoticeable. I haven't had a chance to perform exhaustive testing of the safety palette lately, but I don't recall ever seeing colors from it dither on any browser, except when the display is set to high-color mode.
Figure 2 Original Image
Figure 3 Dithered Image
When a browser does need to perform dithering, then all bets are off as to the exact methodology that will be used to generate the dithered pattern. The operating system itself often provides this functionality, so exactly how the dithering is performed and exactly what colors will be used depends on the colors available in the current palette (see Figures 2 and 3). And the selected palette in Netscape Navigator and Internet Explorer can differ significantly in some instances, so pixel-level differences in dithering would not surprise me.
Other Modes The Palette Manager only comes into play in 256-color mode. This means that the mapping that the OS does between the color an app wants and the color that's available is not only unnecessary, but won't even happen in any of the higher color modes. In other words, virtually everything I've said up until now can be ignored if you aren't in 256-color mode.
There are essentially two different types of non-palettized display modes in Windows: true-color and high-color. At the root of these color modes is the manner in which color is described on the screen. Color, as you know, is made up of red, green, and blue (RGB) components. When you use 0033FF to describe a color, you are saying that you want to use no red, 20 percent green (the 33 you see in the color code is the hexadecimal representation of the decimal number 51, and 51/255 is 20 percent), and 100 percent blue. Keep in mind that I'm referring to percentages.
To store a value such as FF requires 8 bits of data. Thus, to store a value such as 0033FF requires 24 bits of data. In the 256-color mode, the color palette stores 256 color values, each capable of holding a 24-bit color value. The display itself stores an 8-bit value for each pixel, which could reference any entry in this color table. This is a good way to display fairly rich color without using too much memory. Another benefit of 256-color mode is that it is faster than the higher color modes because a screen refresh requires that less than half a megabyte of data be transferred to the display card's screen buffer, while in true-color mode that amount is tripled.
True-color and High-color As I mentioned previously, in 256-color mode the color resolution is 24 bits. So, if you had enough display memory, the best way to allow any color imaginable to be displayed would be to have every pixel on the screen represented by a 24-bit value. This is what true-color mode does. When an application specifies a color for a pixel, there is no need to hand it off for the palette manager to translate to a palette color. Instead, the color is displayed as is.
Let's say you didn't have quite enough memory for true-color mode, but you still had quite a bit. In high-color mode, instead of using 8 bits for each of the three color components in the RGB value (which can each hold a value from 0 to 255), a smaller number is used. Since computers really like numbers stored in 8-bit units, and three 8-bit numbers can be stored in a 24-bit memory location, the next size down from true-color is 16 bit (24-8=16). So, in a 16-bit memory location you can fit three 5-bit color values, each of which can hold a value from 0 to 31.
For both 24-bit mode and 16-bit mode, black is described as 0,0,0. White is described in 24-bit mode by 255,255,255 (or FF,FF,FF in hexadecimal). For a 16-bit color value, you would describe white as 31,31,31. Now remember, each of these values represents the percentage of color to use for that pixel location.
It is also important to remember that applications are going to ask for a color using a 16-bit value. They don't want to have to worry about what display mode the application is using. For a good example of why you wouldn't want to switch between 24-bit values and 16-bit values to accommodate the color value, consider that green is described by 00FF00 in 24-bit mode, but in 16-bit mode it would be 03E0. Also consider the case of a GIF file; as a totally static data file it doesn't have any way to switch between 24-bit mode and 16-bit mode.
All of this means that in high-color mode, a translation is performed between the 24-bit color value that the application asked for and the 16-bit color value that will be displayed. For white and black, the translation is not only simple, but exact. However, what happens if your page or image asks for a color in 24-bit mode that isn't available in 16-bit mode? The answer is that it may dither.
The color will not dither when an 8-bit and 5-bit integer can both describe the exact same percentage value, such as 0 and 100 percent. The question is, are there any other values that are identical in 8-bit and 5-bit integers?
As an 8-bit range, the number 51 indicates exactly a 20 percent intensity. But in a 5-bit range, there isn't any value that exactly equals 20 percent. (6 = 19.35483871 percent, and 7 = 22.58064516 percent). Therefore, any color value that uses 51 (20 percent) references a nonexistent color in high-color mode. If you take the time to calculate all the values, you'll see that there aren't any valuesâ"other then 0 and 100 percentâ"that the two ranges have in common. Thus, the only colors available in all color modes are the ones that use only values of 00 or FF for all of their color components.
Conclusion Fortunately, the issue of color is not quite as bad as you might expect. Once you realize that there are essentially two ways to represent solid color (with a color code and as a GIF image), and then test them in high-color mode in the popular browsers, you will notice that you almost always do get a solid color. This is because the browser is mapping the requested color value using an API (GetNearestColor for you geeks out there) so that it can find the closest match within the available color space. Of the browsers I quickly tested (Internet Explorer 4.0, Internet Explorer 5.5, and Netscape 4.7) I noticed that it was only in Internet Explorer 4.0 on a BGCOLOR request that I sometimes got a dithered result; GIF images using the safety palette were always solid colors (see Figure 4).
Figure 4 GIF Images versus BGCOLOR in Internet Explorer 4.0
To perform the test, I used a screenshot of the safety palette from http://msdn.microsoft.com/workshop/ design/color/safety.asp (which is a GIF image), and then took a screenshot from http://msdn.microsoft.com/workshop/design/color/colorpick.asp which is the same chart, but this time rendered using BGCOLOR (which uses hex color codes to produce each color instead) and then compare the two. Testing in this way can give you an idea of the dithering of the safety palette colors on 256, high-color, and true-color systems in each browser.
| Robert Hess is currently the host of "The MSDN Show" and is a regular contributor to various areas of MSDN. Send e-mail to email@example.com.|
From the October 2000 issue of MSDN Magazine.