231-234.html

WindowsCE.[Essential Windows CE Application Programming].Jon Wiley & Son.zip

<!-- begin main content -->
<td width="100%" valign="top" align="left">


<!-- END SUB HEADER -->

<!--Begin Content Column -->

<FONT FACE="Arial,Helvetica" SIZE="-1">
To access the contents, click the chapter and section titles.
</FONT>
<P>
<B>Essential Windows CE Application Programming</B>
<FONT SIZE="-1">
<BR>
<I>(Publisher: John Wiley & Sons, Inc.)</I>
<BR>
Author(s): Robert Burdick
<BR>
ISBN: 0471327476
<BR>
Publication Date: 03/01/99
</FONT>
<P>
<form name="Search" method="GET" action="http://search.earthweb.com/search97/search_redir.cgi">

<INPUT TYPE="hidden" NAME="Action" VALUE="Search">
<INPUT TYPE="hidden" NAME="SearchPage" VALUE="http://search.earthweb.com/search97/samples/forms/srchdemo.htm">
<INPUT TYPE="hidden" NAME="Collection" VALUE="ITK">
<INPUT TYPE="hidden" NAME="ResultTemplate" VALUE="itk-simple-intrabook.hts">
<INPUT TYPE="hidden" NAME="ViewTemplate" VALUE="view.hts">

<font face="arial, helvetica" size=2><b>Search this book:</b></font><br>
<INPUT NAME="queryText" size=50 VALUE="">&nbsp;<input type="submit" name="submitbutton" value="Go!">
<INPUT type=hidden NAME="section_on" VALUE="on">
<INPUT type=hidden NAME="section" VALUE="http://www.itknowledge.com/reference/standard/0471327476/">

</form>


<!-- Empty Reference Subhead -->

<!--ISBN=0471327476//-->
<!--TITLE=Essential Windows CE Application Programming//-->
<!--AUTHOR=Robert Burdick//-->
<!--PUBLISHER=John Wiley & Sons, Inc.//-->
<!--IMPRINT=Wiley Computer Publishing//-->
<!--CHAPTER=8//-->
<!--PAGES=231-234//-->
<!--UNASSIGNED1//-->
<!--UNASSIGNED2//-->

<CENTER>
<TABLE BORDER>
<TR>
<TD><A HREF="225-231.html">Previous</A></TD>
<TD><A HREF="../ewtoc.html">Table of Contents</A></TD>
<TD><A HREF="234-236.html">Next</A></TD>
</TR>
</TABLE>
</CENTER>
<P><BR></P>
<H3><A NAME="Heading4"></A><FONT COLOR="#000077">Reading and Writing Registry Values</FONT></H3>
<P>The real data stored by the Windows CE registry is kept in the various <I>values</I> contained in each registry key. As described above, registry values can store data of a variety of types, making registry storage very flexible.</P>
<P>A registry key value is like a data slot. Each key can have one or more values for storing information. An application can read and write data from existing registry values, or it can create new values for its purposes. In either case, the application uses <I>RegSetValueEx</I>. This function assigns data to a specified registry value. If the value does not exist, it is created. The syntax of <I>RegSetValueEx</I> is:</P>
<!-- CODE SNIP //-->
<PRE>
  RegSetValueEx(hKey, lpszValueName, Reserved, dwType,
    lpData, cbData);
</PRE>
<!-- END CODE SNIP //-->
<P><I>hKey</I> is the key that contains the value to which data is assigned. <I>lpszValueName</I> is the null-terminated Unicode string name of the value to set. <I>Reserved</I>, again, is reserved for later versions of Windows CE and as such must be set to zero. <I>dwType</I> is one of the data type specifiers. It tells <I>RegSetValueEx</I> what type of data is being placed in the registry value. <I>lpData</I> is a constant BYTE pointer containing the data to be assigned to the value. <I>cbData</I> contains the size, or length in bytes, of the data in <I>lpData</I>.</P>
<P>As an example, let&#146;s say that we wish to create a registry key under the HKEY_LOCAL_MACHINE primary key called &#147;Test.&#148; We then wish to create 20 values in that key named Value0, Value1, and so on up to Value19. Additionally, we want to assign each of these values the DWORD integer corresponding to the number in the value name. For example, the number in Value0 will be 0 and the number in Value1 will be 1.</P>
<P>To accomplish this, our application would do the following:</P>
<!-- CODE //-->
<PRE>
  HKEY hKeyTest;
  DWORD dwDisp, dwSize;
  TCHAR pszValue[MAX_STRING_LENGTH];
  int i;
  if (ERROR_SUCCESS != RegCreateKeyEx(HKEY_LOCAL_MACHINE,
     TEXT("Test"), NULL, NULL, 0, 0,
      NULL, &#38;hKeyTest, &#38;dwDisp))
  &#123;
    MessageBox(NULL, TEXT("Could Not Create Key"),
     TEXT("Registry Error"), MB_ICONEXCLAMATION|MB_OK);
  &#125;
  else
  &#123;
    for (i=0; i&lt;20; i&#43;&#43;)
    &#123;
     dwSize = sizeof(DWORD);
     wsprintf(pszValue, TEXT("Value%d"), i);
     if (ERROR_SUCCESS != RegSetValueEx(hKeyTest,
      pszValue, NULL, REG_DWORD, (CONST BYTE*)&#38;i,
       dwSize))
     &#123;
      MessageBox(NULL, TEXT("Could Not Set Value"),
       pszValue, MB_ICONEXCLAMATION|MB_OK);
     &#125;
    &#125;    //End of for i loop
  &#125;
</PRE>
<!-- END CODE //-->
<P>The first thing we do is attempt to create the HKEY_LOCAL_MACHINE\Test registry key. If this <I>RegCreateKeyEx</I> call fails, we display a message box to that effect. If the create was successful, we proceed to the for loop, which sets the 20 registry values. <I>RegSetValueEx</I> creates each of the registry values if they don&#146;t already exist in the registry. The <I>RegSetValueEx</I> call passes REG_DWORD as the <I>dwType</I> parameter, indicating that the value to be written is a DWORD. The name of each registry value is constructed with the <I>wsprintf</I> call.</P>
<P>Reading a registry value is done with the function <I>RegQueryValueEx</I>:</P>
<!-- CODE SNIP //-->
<PRE>
  RegQueryValueEx(hKey, lpszValueName, lpReserved,
    lpType, lpData, lpcbData);
</PRE>
<!-- END CODE SNIP //-->
<P><I>hKey</I> and <I>lpszValueName</I> have the same meaning as in <I>RegSetValueEx</I>. <I>lpReserved</I> is a reserved DWORD pointer and must be NULL. <I>lpType</I> is a DWORD pointer that contains the registry value&#146;s data type. <I>lpData</I> is a BYTE pointer in which the function returns the value data. <I>lpcbData</I> is a DWORD pointer that contains the length in bytes of the data to be read from the registry value.</P>
<P>The <I>lpcbData</I> parameter deserves some illumination. Otherwise it will haunt your every registry query. You must assign the number of bytes to be read from the particular registry value to the DWORD pointed to by the <I>lpcbData</I> parameter. So far so good. But <I>RegQueryValueEx</I> uses this parameter as a return value as well. It returns the actual number of bytes read from the registry key, which may indeed be different from the number you said to read. For example, you may expect a string you are querying to be 50 bytes long. If the string is really 15 bytes long, <I>RegQueryValueEx</I> will return 15 in <I>lpcbData</I>.</P>
<P>This still sounds OK? Well, maybe, until you try using <I>RegQueryValueEx</I> to read multiple registry keys in a loop <I>and do not reassign lpcsData to the number of bytes you want to read for each query.</I></P>
<P>Let&#146;s look at the following example:</P>
<!-- CODE //-->
<PRE>
  int i;
  DWORD dwSize;
  DWORD dwType;
  TCHAR pszText[128];
  dwSize = 128;
  dwType = REG_SZ;
  for (i=0; i&lt;5; I&#43;&#43;)
  &#123;
    wsprintf(pszText, TEXT("Value%ld"), i);
    RegQueryValueEx(
     hKeyTest,
     pszValue,
     NULL,
     &#38;dwType,
     (LPBYTE)pszText,
     &#38;dwSize);
    //Do something with dwValue
  &#125;
</PRE>
<!-- END CODE //-->
<P>You expect this code to read five Unicode strings of length 128 bytes from five registry values named Value0 through Value4.
</P>
<P>But what if any of the actual strings is less than 128 bytes long? <I>RegQueryValueEx</I> will return the real length of that string in <I>dwSize</I>. The next <I>RegQueryValueEx</I> call will then say to read only as many bytes as were in the last string. At this point, you can count on all the rest of the values read to be completely unreliable. Believe me, the bugs that result from such an oversight are very difficult to track down.</P>
<P>The moral of this story is: Set the <I>lpcbData</I> value properly for each and every call to <I>RegQueryValueEx</I>.</P><P><BR></P>
<CENTER>
<TABLE BORDER>
<TR>
<TD><A HREF="225-231.html">Previous</A></TD>
<TD><A HREF="../ewtoc.html">Table of Contents</A></TD>
<TD><A HREF="234-236.html">Next</A></TD>
</TR>
</TABLE>
</CENTER>


<!-- all of the reference materials (books) have the footer and subfoot reveresed -->
<!-- reference_subfoot = footer -->
<!-- reference_footer = subfoot -->

<!-- BEGIN SUB FOOTER -->
		<br><br>
		</TD>
    </TR>
	</TABLE>

		
	<table width="640" border=0 cellpadding=0 cellspacing=0>
		<tr>
		<td align="left" width=135><img src="/images/white.gif" width=100 height="1" alt="" border="0"></td>
		
		
<!-- END SUB FOOTER -->

<!-- all of the books have the footer and subfoot reveresed -->
<!-- reference_subfoot = footer -->
<!-- reference_footer = subfoot -->

<!-- FOOTER -->
			
		<td width="515" align="left" bgcolor="#FFFFFF">
<font face="arial, helvetica" size="1"><b><a href="/products.html"><font color="#006666">Products</font></a>&nbsp;|&nbsp; <a href="/contactus.html"><font color="#006666">Contact Us</font></a>&nbsp;|&nbsp; <a href="/aboutus.html"><font color="#006666">About Us</font></a>&nbsp;|&nbsp; <a href="http://www.earthweb.com/corporate/privacy.html" target="_blank"><font color="#006666">Privacy</font></a> &nbsp;|&nbsp; <a href="http://www.itmarketer.com/" target="_blank"><font color="#006666">Ad Info</font></a> &nbsp;|&nbsp; <a href="/"><font color="#006666">Home</font></a></b>
		<br><br>
		
		Use of this site is subject to certain <a href="/agreement.html">Terms &amp; Conditions</a>, <a href="/copyright.html">Copyright &copy; 1996-1999 EarthWeb Inc.</a><br> 
All rights reserved.  Reproduction whole or in part in any form or medium without express written permision of EarthWeb is prohibited.</font><p>
</td>
		</tr>
</table>
</BODY>
</HTML>

<!-- END FOOTER -->