Andy

Extract values from vary controls and Write it on XML

2012-01-04T12:20:00.000+09:00

This has found in forum who shared the problem and solution as mentioned above title.
Background:
A form contains many controls, such as TextBox, ComboBox and etc...
Then, we need to extract the value from these options.

The code example is as below:

foreach(Control control in this.Controls)
{
    //here 'this' is representing the form you want to iterate through

    //you can check whether it is a combobox or a text box
    if(control.GetType() == typeof(Combobox))
    {
        //this is a combo box
    }
    else if(control.GetType() == typeof(Textbox))
    {
        //this is a text box
    }
}

This is a nice example as for beginner like me ^^/

Link: http://stackoverflow.com/questions/6400382/how-do-i-extract-values-from-controls-and-write-it-on-xml

Save and Read Combo Box Items from an XML File

2012-01-02T21:06:00.001+09:00

Introduction
When discussing file processing, we mentioned that it is sometimes necessary to automatically save a file when an application exits, without any intervention from the user. You can also solve this exact problem using XML. The ever growing strength of XML is in its ability to let modify a file however but still make that file usable by any environment that needs its content.

We are going to create an XML file that holds a list of items for a combo box. Once the file exists, it can be processed or modified by any application that can read XML. We will load the file automatically when the application opens and retrieve the values of the elements to complete a combo box. While using the application, we will allow the user to change the list. When the application closes, we will retrieve the list of items from the combo box and update (in reality) recreate the list that includes the new items.

Practical Learning: Using XML Values

1. Related link:Start Visual C# and create a new Windows Forms Application named XmlListUpdate1
2. To create an XML file, on the main menu, click Project -> Add New Item...
3. In the Templates list, click XML File (.xml)
4. In the Name box, replace the string with ISFlavors and click open
5. Change the contents of the file as follows:

6. Save this XML file in your bin\Debug folder

7. Design the form as follows:

http://www.functionx.com/vcsharp2003/xml/comboboxitems.htm

http://csharp.net-informations.com/xml/how-to-read-xml.htm

How to read APP.CONFIG for user defined run-time parameters

2012-01-01T20:26:00.002+09:00

These are the steps involved in defining runtime parameters and using them in your code.
1. Create a App.Config file
2. Define the runtime parameters and provide values for these
3. Access these parameters in your code
4. Verify changing the parameter value at runtime affects the application

Step 1: Create App.Config file
1a. Create a Console Application
1b. In Solution Explorer, right click on project. Add->New Item. Select Application Configuration file. This file will be added to your project.

Step 2: Define the runtime parameters and provide values for these
2a. Open App.Config.
2b. Define the keys and values for your runtime parameters.

Example:

You can define any key and provide values. Ensure you don’t have duplicate keys.

Step 3: Access these parameters in your code

3a. Add a refernce System.Configuration DLL.¹
3b. Add the following lines in your code. You can directly add these lines in Main.

Example:
string name = System.Configuration.ConfigurationManager.AppSettings["OperatorName"];
Console.Writeline("Welcome " + name);

string level = System.Configuration.ConfigurationManager.AppSettings["LoggerLevel"];
Console.Writeline("Logger level: " + level);

3c. Build your project and execute it.The output should be:

Welcome Rita
Logger level: 5

Step 4: Verify changing the parameter value at runtime affects the application
4a. When you build your project, the App.Config file is copied to your Debug/Release folder with the name .exe.config. My project is named UseAppConfig. The App.Config in my Debug folder is UseAppConfig.exe.config

Open the .config file in your working directory (Debug/Release). Change the values to Mary and 1. In the same folder you will see your executbale. Double click on this and you should see the new values.²

You are all set. You can identify all those parameters that make sense as runtime parameters, define a meaningful key for each parameter and start using it. You no longer have to build your application every time you want to change the parameter value.

Notes
1: You need this reference only if you are using .NET 2.0
2: If you change the App.Config from Visual Studio IDE, then you need to rebuild your project to see the new values.

Visual C# Controls Tutorial - ComboBoxes

2011-12-31T02:52:00.001+09:00

Creating Multiple Forms in C#.NET

2011-12-26T18:53:00.001+09:00

There aren't many programmes that have only one form. Most programmes have other forms that are accessible from the main one that loads at start up. In this section, you'll learn how to create programmes with more than one form in C#.NET.
The programme we'll create is very simple one. It will have a main form with a text box and a button. When the button is clicked, it will launch a second form. On the second form, we'll allow a user to change the case of the text in the text box on form one.
Here's what form one looks like:

Design the above form. Set the Name property of the text box to txtChangeCase. For the Text property, add some default text, but all in lowercase letters. Set the Name property of the button to btnFormTwo.
Adding a new form to the project is easy. Click Project from the menu bar at the top of the Visual C# software. From the Project menu, select Add New Windows Form. You'll see the Add New Item dialogue box appear. Make sure Windows Form is selected. For the Name, leave it on the default of Form2.cs. When you click OK, you should see a new blank form appear:

It will also be in the Solution Explorer on the right:

Adding the form to the project is the easy part - getting it to display is an entirely different matter!
To display the second form, you have to bear in mind that forms are classes. When the programme first runs, C# will create an object from your Form1 class. But it won't do anything with your Form2 class. You have to create the object yourself.
So double click the button on your Form1 to get at the coding window.
To create a Form2 object, declare a variable of Type Form2:

Form2 secondForm;

Now create a new object:

secondForm = new Form2();

Or if you prefer, put it all on one line:

Form2 secondForm = new Form2();

What we've done here is to create a new object from the Class called Form2. The name of our variable is secondForm.
To get this new form to appear, you use the Show( ) method of the object:

secondForm.Show();

Your code should now look like this:

Run your programme and test it out. Click your button and a new form should appear - the blank second form.
However, there's a slight problem. Click the button again and a new form will appear. Keep clicking the button and your screen will be filled with blank forms!
To stop this from happening, move the code that creates the form outside of the button. Like this:

Try your programme again. Click the button and you won't get lots of forms filling the screen.

Related Link:
1. http://www.homeandlearn.co.uk/csharp/csharp_s13p1.html

Split Container Control in C#

2011-12-25T12:47:00.000+09:00

What is Split Container control in C#?
Split Container control provides functionality of a splitter to divide and resize two controls.You can place it at form horizontally or vertically by specifiying Orientation property each represents left/top and right/bottom panels respectively.

Useful properties:

AutoScroll: This property when set to true, allows scroll bars to be displayed.
BackColor: The background color of the SplitContainer is defaulted to System.Drawing.SystemColors.Control, but this can be set to any color you like. The whole of the SplitContainer changes color, however, each Panel can have its own background color.
BackgroundImage: Instead of a single color, an image can be displayed as the background. The image only appears in the splitter bar.
BorderStyle: This property determines if the panel is outlined with no visible border (None), a plain line (FixedSingle), or a shadowed line (Fixed3D).
Dock: Determines which SplitContainer borders are attached to the edges of the container. When a SplitContainer control is dropped onto a container, this property defaults to Fill.
FixedPanel: Determines which SplitContainer panel remains the same size when the container is resized. This property takes a value from the FixedPanel enumeration, the default value is None:
None: Specifies that neither SplitContainer.Panel1, SplitContainer.Panel2 is fixed. A Control.Resize event affects both panels.
Panel1: Specifies that SplitContainer.Panel1 is fixed. A Control.Resize event affects only SplitContainer.Panel2.
Panel2: Specifies that SplitContainer.Panel2 is fixed. A Control.Resize event affects only SplitContainer.Panel1.
IsSplitterFixed: Gets or sets a value indicating whether the splitter is fixed or movable.
Orientation:Gets or sets a value indicating the Horizontal or Vertical orientation of the SplitContainer panels.
Panel1: Gets the left panel of a vertical SplitContainer or the top panel of a horizontal SplitContainer. When you click on this property in the IDE properties pane, you can edit the properties of the underlying Panel.
Panel1Collapsed: Determines whether Panel1 is collapsed or expanded. When this value is true, Panel1 is hidden and Panel2 expands to fill the SplitContainer. This property is mutually exclusive with Panel2Collapsed.
Panel1MinSize: Determines the minimum distance in pixels of the splitter from the left or top edge of Panel1.
Panel2: Gets the right panel of a vertical SplitContainer or the bottom panel of a horizontal SplitContainer. When you click on this property in the IDE properties pane, you can edit the properties of the underlying Panel.
Panel2Collapsed: Determines whether Panel2 is collapsed or expanded. When this value is true, Panel2 is hidden and Panel1 expands to fill the SplitContainer. This property is mutually exclusive with Panel1Collapsed.
Panel2MinSize: Determines the minimum distance in pixels of the splitter from the right or bottom edge of Panel2.
SplitterDistance: Determines the location of the splitter, in pixels, from the left (Orientation = Vertical) or top (Orientation = Horizontal) edge of the SplitContainer.
SplitterIncrement: Gets or sets a value representing the increment of splitter movement in pixels.
SplitterRectangle: Gets the size and location of the splitter relative to the SplitContainer.
SplitterWidth: Determines the width of the splitter in pixels.

Figure 1 shows the example of the Splitter Container Control in a form.

Calling Win32 DLLs in C# with P/Invoke

2011-11-30T12:51:00.001+09:00

Unmanaged Code

BOOL MessageBeep(

UINT uType // beep type

);

Managed Code

[DllImport ("User32.dll")]

static extern Boolean MessageBeep (UInt32 beepType);

Note:

Static

1.The MessageBeep method was declared as static.

2.This is a requirement for P/Invoke methods because there is no consistent notion of an instance in the Window API.

Extern

1. It is not a method call, but an extern method definition.

2. This is your hint to the compiler that you mean for the method to be implemented by a function exported from a DLL, and therefore there is no need for you to supply a method body.

3. P/Invoke methods are nothing more than metadata that the just-in-time (JIT) compiler uses to wire managed code to an unmanaged DLL function at run time.

4. An important piece of information required to perform this wiring to the unmanaged world is the name of the DLL from which the unmanaged method is exported.

6. The DllImport custom attribute that precedes the MessageBeep method declaration. In this case, you can see that the MessageBeep unmanaged API is exported by the User32.dll in Windows.

7. The call into the unmanaged MessageBeep function can be performed by any managed code that finds the extern MessageBeep declaration within scope.

8. The call is made like any other call to a static method. It is this commonality with any other managed method calls that introduces the requirement of data marshaling.

9. One of the rules of C# is that its call syntax can only access CLR data types such as System.UInt32 and System.Boolean.

10.C# is expressly unaware of C-based data types used in the Windows API such as UINT and BOOL, which are just typedefs of the C language types.

11.The extern method must be defined using CLR types, as you saw in the preceding code snippet.

12. This requirement to use CLR types that are different from, but compatible with, the underlying API function types is one of the more difficult aspects of using P/Invoke.

Figure 1 MessageBeep, Interop Done Well

namespace Wintellect.Interop.Sound{
   using System;
   using System.Runtime.InteropServices;
   using System.ComponentModel;

   sealed class Sound{
      public static void MessageBeep(BeepTypes type){
         if(!MessageBeep((UInt32) type)){
            Int32 err = Marshal.GetLastWin32Error();
            throw new Win32Exception(err);
         }
      }

      [DllImport("User32.dll", SetLastError=true)]
      static extern Boolean MessageBeep(UInt32 beepType);

      private Sound(){}
   }

   enum BeepTypes{ 
      Simple = -1,
      Ok                = 0x00000000,
      IconHand          = 0x00000010,
      IconQuestion      = 0x00000020,
      IconExclamation   = 0x00000030,
      IconAsterisk      = 0x00000040
   }
}

Starting from the top, you will notice that an entire type named Sound is devoted to MessageBeep. If I need to add support for playing waves using the Windows API function PlaySound, I could reuse the Sound type. However, I am not offended by a type that exposes a single public static method. This is application code, after all. Notice also that Sound is sealed and defines an empty private constructor. These are just details to keep a user from mistakenly deriving from or creating an instance of Sound.

The next feature of the code in Figure 1 is that the actual extern method where P/Invoke occurs is a private method of Sound. This method is exposed only indirectly by the public MessageBeep method, which takes a parameter of type BeepTypes. This extra level of indirection is a critical detail that provides the following benefits.

First, should a future managed method of beeping be introduced in the class library, you can re-tool your public MessageBeep method to use the managed API without having to change the rest of the code in your application.

A second benefit of the wrapper method is this: when you P/Invoke, you waive your right to the protection from access violations and other low-level catastrophes, normally provided by the CLR. A buffer method, even if it does nothing but pass parameters through, allows you to protect the rest of your application from access violations and the like. The buffer method localizes any potential bugs introduced by the P/Invoke call.

The third and final benefit of hiding your private extern methods behind a public wrapper is the opportunity to add some minimum CLR style to the method. For example, in Figure 1 I converted a Boolean failure returned by the Windows API function into a more CLR-like exception. I also defined an enumerated type named BeepTypes whose members correspond to the define values used with the Windows API. Since C# doesn't support defines, managed enumerated types are used to avoid scattering magic numbers throughout your application code.

This final benefit of a wrapper method is admittedly minor for a simple Windows API function like MessageBeep. But as you begin to call into more complex unmanaged functions, you will find a manual translation from the Windows API style to a more CLR-friendly approach increasingly beneficial. The more you plan to reuse your interop functionality throughout your applications, the more design thought you should put into the wrapper. Meanwhile I see no shame in non-object-oriented static wrapper methods with CLR-friendly parameters.

The DLL Import Attribute

The DllImportAttribute type plays an important part in the P/Invoke story for managed code. The DllImportAttribute's primary role is to indicate to the CLR which DLL exports the function that you want to call. The name of the DLL in question is passed as the single constructor parameter to the DllImportAttribute.

Optional DllImportAttribute Properties

In addition to indicating the host DLL, the DllImportAttribute also includes a handful of optional properties, four of which are particularly interesting: EntryPoint, CharSet, SetLastError, and CallingConvention.

EntryPoint You can set this property to indicate the entry point name of the exported DLL function in cases where you do not want your extern managed method to have the same name as the DLL export. This is particularly useful when you are defining two extern methods that call into the same unmanaged function. Additionally, in Windows you can bind to exported DLL functions by their ordinal values. If you need to do this, an EntryPoint value such as "#1" or "#129" indicates the ordinal value of the unmanaged function in the DLL rather than a function name.

CharSet When it comes to character sets, not all versions of Windows are created equal. The Windows 9xfamily of products lack significant Unicode support, while the Windows NT and Windows CE flavors use Unicode natively. And sitting on top of these operating systems, the CLR uses Unicode for its internal representation of String and Char data. But never fear—the CLR automatically makes the necessary translations from Unicode to ANSI when calling into Windows 9x API functions.

If your DLL function doesn't deal with text in any way, then you can ignore the CharSet property of the DllImportAttribute. However, when Char or String data is part of the equation, set the CharSet property to CharSet.Auto. This causes the CLR to use the appropriate character set based on the host OS. If you don't explicitly set the CharSet property, then its default is CharSet.Ansi. This default is unfortunate because it negatively affects the performance of text parameter marshaling for interop calls made on Windows 2000, Windows XP, and Windows NT®.

The only time you should explicitly select a CharSet value of CharSet.Ansi or CharSet.Unicode, rather than going with CharSet.Auto, is when you are explicitly naming an exported function that is specific to one or the other of the two flavors of Win32 OS. An example of this is the ReadDirectoryChangesW API function, which exists only in Windows NT-based operating systems and supports Unicode only; in this case you should use CharSet.Unicode explicitly.

Sometimes it is unclear whether a Windows API has a character set affinity. A surefire way to find out is to check the C-language header file for the function in the Platform SDK. (If you are unsure which header file to look in, the Platform SDK documentation lists the header file for each API function.) If you find that the API function is really defined as a macro that maps to a function name ending in A or W, then character set matters for the function that you are trying to call. An example of a Windows API function that you might be surprised to learn has A and W versions is the GetMessage API declared in WinUser.h.

SetLastError Error handling is an important but frequently avoided aspect of programming. And when you are P/Invoking, you are faced with the additional challenge of dealing with the differences between Windows API error handling and exceptions in managed code. I have a few suggestions for you.

If you are using P/Invoke to call into a Windows API function for which you use GetLastError to find extended error information, then you should set the SetLastError property to true in the DllImportAttribute for your extern method. This applies to the majority of extern methods.

This causes the CLR to cache the error set by the API function after each call to the extern method. Then, in your wrapper method, you can retrieve the cached error value by calling the Marshal.GetLastWin32Error method defined on the System.Runtime.InteropServices.Marshal type in the class library. My advice is to check for error values that you expect from the API function and throw a sensible exception for these values. For all other failure cases, including those where failure wasn't expected at all, throw the Win32Exception defined in the System.ComponentModel namespace and pass it the value returned by Marshal.GetLastWin32Error. If you take a look back at the code in Figure 1, you will see that I took this approach in my public wrapper around the extern MessageBeep method.

CallingConvention The last and probably least important of the DllImportAttribute properties that I will cover here is CallingConvention. This property lets you indicate to the CLR which function calling convention it should use for parameters on the stack. The default value of CallingConvention.Winapi is your best bet and will work in most cases. However, if the call isn't working, you might check the declaring header file in the Platform SDK to see if the API function you are calling is one of the odd APIs that bucks the calling convention standard.

In general, the calling convention of a native function, such as a Windows API function or a C-runtime DLL function, describes how the parameters are pushed onto and cleaned off the thread's stack. Most Windows API functions push the last parameter of a function onto the stack first, and then it is the called function's job to clean up the stack. By contrast, many of the C-runtime DLL functions are defined to push the method parameters onto the stack in the order they appear in the method signature, leaving stack cleanup to the caller.

Fortunately you only need a peripheral understanding of calling conventions to get P/Invoke calls to work. In general, starting with the default, CallingConvention.Winapi, is your best bet. And then, with C-runtime DLL functions and a very few functions you might have to change the convention to CallingConvention.Cdecl.

Data Marshaling

Data marshaling is a challenging aspect of P/Invoke. When passing data between the managed and unmanaged worlds, the CLR follows a number of rules that few developers will encounter often enough to memorize. Mastery of the details, though, is normally unnecessary unless you are a class library developer. Application developers who need to interop only occasionally should still understand some fundamentals of data marshaling to get the most out of P/Invoke on the CLR.

Marshaling Numerical and Logical Scalars

The majority of the Windows OS is written in C. As a result, the data types used with the Windows API are either C types or C types that are relabeled through a type definition or macro definition. Let's look at data marshaling without pointers. To keep things simple, I'll focus first on numbers and Boolean values.

When passing a parameter by value to a Windows API function, you need to know the answers to the following questions:

Is the data fundamentally integral or floating-point?
If the data is integral, is it signed or unsigned?
If the data is integral, how wide is it in bits?
If the data is floating-point, is it single or double precision?

Sometimes the answers are obvious, and other times they aren't. The Windows API redefines the fundamental C data types in a variety of ways. Figure 2 lists some common C and Win32 data types, along with their specifications and a common language runtime type with a matching specification.

Figure 2 Non-Pointer Data Types

Win32 Types	Specification	CLR Type
char, INT8, SBYTE, CHARâ€	8-bit signed integer	System.SByte
short, short int, INT16, SHORT	16-bit signed integer	System.Int16
int, long, long int, INT32, LONG32, BOOLâ€ , INT	32-bit signed integer	System.Int32
__int64, INT64, LONGLONG	64-bit signed integer	System.Int64
unsigned char, UINT8, UCHARâ€ , BYTE	8-bit unsigned integer	System.Byte
unsigned short, UINT16, USHORT, WORD, ATOM, WCHARâ€ , __wchar_t	16-bit unsigned integer	System.UInt16
unsigned, unsigned int, UINT32, ULONG32, DWORD32, ULONG, DWORD, UINT	32-bit unsigned integer	System.UInt32
unsigned __int64, UINT64, DWORDLONG, ULONGLONG	64-bit unsigned integer	System.UInt64
float, FLOAT	Single-precision floating point	System.Single
double, long double, DOUBLE	Double-precision floating point	System.Double
â€ In Win32 this type is an integer with a specially assigned meaning; in contrast, the CLR provides a specific type devoted to this meaning.

In general, as long as you select a CLR type whose specification matches that of the Win32 type for the parameter, your code will work. There are some special cases, however. For example, the BOOL type definition in the Windows API is a signed 32-bit integer. However, BOOL is used to indicate a Boolean value of true or false. While you could get away with marshaling a BOOL parameter as a System.Int32 value, you will get a more appropriate mapping if you use the System.Boolean type. Character type-mapping is similar to BOOL in the sense that there is a specific CLR type, System.Char, to address character meaning.

With this information, it might be helpful to step through an example. Sticking with the beep theme, let's try the Kernel32.dll low-level Beep, which makes a beep through the computer's speaker. The Platform SDK documentation for the method can be found at Beep. The native API is documented as follows:

BOOL Beep(
  DWORD dwFreq,      // Frequency
  DWORD dwDuration   // Duration in milliseconds
);

In terms of parameter marshaling, your job is to figure out what CLR data types are compatible with the DWORD and BOOL data types used with the Beep API function. Reviewing the chart in Figure 2, you'll see that DWORD is a 32-bit unsigned integer value, as is the CLR type System.UInt32. This means that you can use UInt32 values for the two parameters to Beep. The BOOL return value is an interesting case because the chart tells us that in Win32, BOOL is a 32-bit signed integer. Therefore, you could use a System.Int32 value for the return value from Beep. However, the CLR also defines the System.Boolean type for the semantic meaning of a Boolean value, so you should use that instead. The CLR will marshal the System.Boolean value as a 32-bit signed integer by default. The extern method definition shown here is the resulting P/Invoke method for Beep:

[DllImport("Kernel32.dll", SetLastError=true)]
static extern Boolean Beep(
   UInt32 frequency, UInt32 duration);

Parameters that are Pointers

Many Windows API functions take a pointer as one or more of their parameters. Pointers increase the complexity of marshaling data because they add a level of indirection. Without pointers, you pass data by value on the thread's stack. With pointers, you pass data by reference, by pushing a memory address to the data onto the thread's stack. The function then accesses the data indirectly through the memory address. There are multiple ways to express this additional level of indirection using managed code.

In C#, if you define a method parameter as ref or out, then the data is passed by reference rather than by value. This is true, even if you are not using Interop, but are just calling from one managed method to another. For example, if you pass a System.Int32 parameter by ref, then you pass the address to the data on the thread's stack rather than the integer value itself. Here is an example of a method defined to receive an integer value by reference:

void FlipInt32(ref Int32 num){
   num = -num;
}

Here, the FlipInt32 method takes the address of an Int32 value, accesses the data, negates it, and assigns the negated value to the original variable. In the following code, the caller's variable x would have its value changed from 10 to -10 by the FlipInt32 method:

Int32 x = 10;
FlipInt32(ref x);

This ability, in managed code, can be reused to pass pointers to unmanaged code. For example, the FileEncryptionStatus API function returns file encryption status as a 32-bit unsigned bitmask. The API is documented as shown here:

BOOL FileEncryptionStatus(
  LPCTSTR lpFileName,  // file name
  LPDWORD lpStatus     // encryption status
);

Notice that the function doesn't return the status using its return value, but instead returns a Boolean value indicating whether the call succeeded. In the success case, the actual status value is returned through the second parameter. The way this works is that the caller passes the function a pointer to a DWORD variable, and the API function populates the pointed-to memory with the status value. The following snippet shows a possible extern method definition to call into the unmanaged FileEncryptionStatus function:

[DllImport("Advapi32.dll", CharSet=CharSet.Auto)]
static extern Boolean FileEncryptionStatus(String filename, 
   out UInt32 status);

The definition uses the out keyword to indicate a by-ref parameter for the UInt32 status value. I could have selected the ref keyword here as well, and in fact both result in the same machine code at run time. The out keyword is simply a specialization of a by-ref parameter that indicates to the C# compiler that the data being passed is only being passed out of the called function. In contrast, with the ref keyword the compiler assumes that data may flow both in and out of the called function.

Another cool aspect of out and ref parameters in managed code is that the variable whose address you pass as the by-ref parameter may be a local variable on the thread's stack, an element of a class or structure, or it can be a reference to an element in an array of the appropriate data type. This caller flexibility makes by-ref parameters a good starting point for marshaling pointers to buffers, as well as to single data values. I would only consider marshaling a pointer as a more complex CLR type such as a class or an array object after I found that a ref or an out parameter did not meet my needs.

If you are unfamiliar with C syntax or making calls into the Windows API functions, then sometimes it can be difficult to know if a method parameter requires a pointer. A common indicator is if the parameter type starts with the letter P or the letters LP such as LPDWORD or PINT. In both of these examples the LP and P indicate that the parameter is a pointer, and the data type that they point to would be DWORD or INT, respectively. In some cases, however, the API function is defined as a pointer directly using the asterisk symbol (*) in C-language syntax. The following code snippet shows an example of this:

void TakesAPointer(DWORD* pNum);

As you can see, the preceding function's single parameter is a pointer to a DWORD variable.

When marshaling pointers through P/Invoke, ref and out are only used with value types in managed code. You can tell a parameter is a value type when its CLR type is defined using the struct keyword. Out and ref are used to marshal pointers to these data types because normally a value type variable is the object or data, and you don't have a reference to a value type in managed code. In contrast, the ref and out keywords are not necessary when marshaling reference type objects because the variable already is a reference to the object.

If you are unfamiliar with the difference between reference types and value types you can find more information on the topic in the .NET column in the December 2000 issue of MSDN® Magazine. Most CLR types are reference types; however, all of the primitive types such as System.Int32 and System.Boolean are value types with the exceptions of System.String and System.Object.

Marshaling Opaque Pointers: a Special Case

Sometimes in the Windows API a method takes or returns a pointer that is opaque, which means that the pointer value is technically a pointer but your code doesn't use it directly. Instead, your code passes the pointer back to Windows for subsequent reuse.

A very common example of this is the notion of a handle. In Windows, internal data structures ranging from files to buttons on the screen are represented to application code as handles. A handle is really an opaque pointer or pointer-width data value that your application uses to represent the internal OS construct.

Occasionally, API functions also define opaque pointers to be of the PVOID or LPVOID types. These types in the Windows API definitions mean that the pointer has no type.

When an opaque pointer is returned to (or expected from) your application, you should marshal the parameter or return value as a special type in the CLR called System.IntPtr. When you use the IntPtr type it is not common to use an out or ref parameter because an IntPtr is intended to hold a pointer directly. However, if you are marshaling a pointer to a pointer, then a by-ref parameter to an IntPtr is appropriate.

The System.IntPtr type has a special property in the CLR type system. Unlike the rest of the basic types in the system, IntPtr does not have a fixed size. Instead, its size at run time is based on the natural pointer size of the underlying operating system. This means that in 32-bit Windows IntPtr variables will be 32 bits in width, and in 64-bit Windows the just-in-time compiler emits code that treats IntPtr values as 64-bit values. This automatic resizing is very useful when marshaling opaque pointers between managed and unmanaged code.

Remember, any API function that returns or accepts a handle is really working with an opaque pointer. Your code should marshal handles in Windows as System.IntPtr values.

You can cast IntPtr values to and from 32-bit and 64-bit integer values in managed code. However, since the pointers are supposed to be opaque when used with Windows API functions, you should have no need to do anything with the values but store them and pass them to extern methods. Two exceptions to the store-and-pass-only rule are when you need to pass a null pointer value to an extern method and when you need to compare an IntPtr value with null. To do this, rather than cast zero to System.IntPtr, you should use the Int32.Zero static public field on the IntPtr type to get the null value for comparing or assigning.

Marshaling Text

Working with textual data is common in programming. Text adds some wrinkles to the interop story for two reasons. First, the underlying operating system may use Unicode to represent strings or it may use ANSI. In some rare cases, such as with the MultiByteToWideChar API function, the two parameters to the function disagree on character set.

The second reason that working with text when P/Invoking requires you to have some special understanding is that C and the CLR each deal with text differently. In C, a string is really only an array of char values, typically terminating in a null. Most of the Windows API functions deal with strings on these terms, either as an array of char values in the ANSI case or an array of wchar values in the case of Unicode.

Fortunately, the CLR is designed to be very flexible when marshaling text so that you can get the job done, regardless of what the Windows API function expects from your application. Here are the primary considerations to keep in mind:

Is your application passing text data to the API function or does string data pass back from the API function to your application? Or both?
What managed type should your extern method use?
What unmanaged string format does the API function expect?

Let's address this last concern first. Most of the Windows API functions take LPTSTR or LPCTSTR values. These are modifiable and non-modifiable buffers, respectively (from the function's point of view), which contain null-terminated character arrays. The "C" stands for constant and means that information will not be passing out of the function using that parameter. The "T" in LPTSTR indicates that this parameter can be either Unicode or ANSI depending on the character set you choose and depending on the character set of the underlying operating system. Since most string parameters are one of these two types in the Windows API, the CLR defaults work for you so long as you selected CharSet.Auto on your DllImportAttribute.

However, some API functions or custom DLL functions represent strings in different ways. If you run across one of these functions, you can decorate your extern method's string parameter with the MarshalAsAttribute and indicate a string format other than the default LPTSTR. For more information on the MarshalAsAttribute, see the Platform SDK documentation topic at MarshalAsAttribute Class.

Now let's look at the direction in which string information is being passed between your code and the unmanaged function. There are two ways that you can know which direction the information is being passed in when working with strings. The first and most reliable method is to understand the purpose of the parameter in the first place. For example, if you are calling a parameter with a name like CreateMutex and it takes a string, then you can imagine that the string information passes from your application to the API function. Meanwhile, if you call GetUserName, then the function name suggests that string information passes from the function to your application.

In addition to the rationalization approach, the second way to find out which direction the information flows in is to look for the letter "C" in the API parameter type. For example, the GetUserName API function's first parameter is defined as type LPTSTR, which stands for long-pointer to a Unicode or ANSI string buffer. But CreateMutex's name parameter is typed as LTCTSTR. Notice that here you have the same type definition, but with the addition of the letter "C" to indicate that the buffer is constant and will not be written to by the API function.

Once you have established whether the text parameter is input only or input/output, you can determine which CLR type to use for the parameter type. Here are the rules. If the string parameter is input only, use the System.String type. Strings are immutable in managed code, and are well suited to be used as buffers that will not be changed by the native API function.

If the string parameter can be input and/or output, then use the System.StringBuilder type. The StringBuilder type is a useful class library type that helps you build strings efficiently, and it happens to be great for passing buffers to native functions that the functions fill with string data on your behalf. Once the function call has returned, you need only call ToString on the StringBuilder object to get a String object.

The GetShortPathName API function is great for showing when to use String and when to use StringBuilder because it takes only three parameters: an input string, an output string, and a parameter that indicates the length in characters of the output buffer.

The commented documentation for the unmanaged GetShortPathName function in Figure 3 indicates both an input and output string parameter. This leads to the managed extern method definition, also shown in Figure 3. Notice that the first parameter is marshaled as a System.String because it is an input-only parameter. The second parameter represents an output buffer, and System.StringBuilder is used.

Figure 3 GetShortPathName Declarations

// ** Documentation for Win32 GetShortPathName() API Function
// DWORD GetShortPathName(
//   LPCTSTR lpszLongPath,      // file for which to get short path 
//   LPTSTR lpszShortPath,      // short path name (output)
//   DWORD cchBuffer            // size of output buffer
// );

[DllImport("Kernel32", CharSet = CharSet.Auto)]
static extern Int32 GetShortPathName(
   String path,                // input string
   StringBuilder shortPath,    // output string
   Int32 shortPathLength);     // StringBuilder.Capacity

Summing it Up

The P/Invoke features covered in this month's column are sufficient to call many of the API functions in Windows. However, if your interop needs are significant, you will eventually find yourself marshaling complex data structures and perhaps even needing access to memory directly through pointers in managed code. In fact, interop into native code can be a veritable Pandora's box of details and low-level bits. The CLR, C#, and managed C++ offer many features to help; perhaps in a later installment of this column I will cover advanced P/Invoke topics.

Meanwhile, whenever you find that the .NET Framework Class Library won't play a sound for you or perform some other bit of magic on your behalf, you know how to lean on the good old Windows API for some assistance.

Difference between Unmanaged Code and Managed Code

2011-11-06T19:54:00.001+09:00

Recently, I'm starting to develop laser ultrasonic scanning system in .Net platform. In the passed, I was using LabVIEW 8.6 to run the system. However, I would like to try with this new platform, where I can learn extra new programming language which lead me easy to compete in coming future.

Before I start to develop the codes for the full system, I have wrapped the unmanaged DLL in .Net using Marshal function. For that, I have to know the difference between the unmanaged and managed DLLs. The following are the definition and different between both.

Managed Code

Managed code is what Visual Basic .NET and C# compilers create. It runs on the CLR (Common Language Runtime), which, among other things, offers services like garbage collection, run-time type checking, and reference checking. So, think of it as, "My code is managed by the CLR."

Visual Basic and C# can only produce managed code, so, if you're writing an application in one of those languages you are writing an application managed by the CLR. If you are writing an application in Visual C++ .NET you can produce managed code if you like, but it's optional.

Umanaged code

Unmanaged code compiles straight to machine code. So, by that definition all code compiled by traditional C/C++ compilers is 'unmanaged code'. Also, since it compiles to machine code and not an intermediate language it is non-portable.

No free memory management or anything else the CLR provides.

Since you cannot create unmanaged code with Visual Basic or C#, in Visual Studio all unmanaged code is written in C/C++.

Further links:
http://en.wikipedia.org/wiki/Managed_code

Why should we adopt LabVIEW FPGA as a tool for developing FPGA Project?

2011-04-13T22:42:00.001+09:00

Thanks for your questions and I hope I can answer them appropriately

1. LabVIEW FPGA utilizes the intuitive graphical dataflow language of LabVIEW to target FPGA technology. LabVIEW is particularly nice for FPGA programming because of its ability to represent parallelism inherent to FPGAs. It also serves as a software-like programming experience with loops and structures which has become a focus of industry lately with C-to-gates and other abstraction efforts. Here are some general comparison along the vectors you mentioned

Code Size and speed optimization - LabVIEW FPGA is a programming language. As such, one can program badly and create designs that are too big to fit on a chip and too slow to meet timing. However, there are two main programming paradigms which you can use. The normal LabVIEW dataflow programming (meaning outside a single-cycle loop) adds registers in order to enforce dataflow and synchronization in parity with the LabVIEW model of computation. As with any abstraction, this use of registers is logic necessary to enforce LabVIEW dataflow and might not be what an expert HDL programmer would create. You trade off the simplicity of LabVIEW dataflow in this case. On the other hand, when you program inside a Single-Cycle timed loop you can achieve size and speed efficiencies comparable to many VHDL implementations. We have had many users that understand that way LabVIEW is transformed to hardware and program in such a way to create very efficient and complex systems.

Development Time - Compared to VHDL many of our users get near infinite improvements in development time due to the fact that they do not know (nor do they have to know) VHDL or Verilog. Someone who knows LabVIEW can now reach the speeds and parallelism afforded by FPGAs without learning a new language. For harware engineers (that might actually have an alternative to LabVIEW) there are still extreme time saving aspects of LabVIEW including ready-made I/O interfaces, Simple FIFO DMA transfers, stichable IP blocks, and visualizable parallism. I talk to many hardware engineers that are able to drastically improve development time with LabVIEW, especially since they are more knowledgable about the target hardware.

Compilation Time - Comparable to slightly longer to due to the extra step of generating intermediate files from the LabVIEW diagram, and the increased level of hierarchy in the design to handle abstraction.

Verification Time - One of our key development initiatives moving forward is increased debugging capabilities. Today we have the abilities to functionally simulate anything included in LabVIEW FPGA, and we recently added simluation capabilities for Imported IP through the IP Integration node on NI Labs and the ability to excite your design with simulated I/O. This functional simualation is very fast and is great for verification and quick-turn design iteration. However, we still want to provide more debugging from the timing prespective with better cycle-accurate simulation. Although significantly slower than functional simulation. Cycle-accuracy give us the next level of verification before compilation. The single cycle loop running in emulation mode is cycle accurate simluation, but we want more system level simulation moving forwrad. Finally, we have worked to import things like Xilinx chipscope (soon to be on NI Labs) for on-chip debugging, which is the final step in the verification process. In terms of verification time there are aspects (like functional simulation) that are faster than traditional methods and others that are comparable, and still other that we are continuing to refine.

Ability to develop in the future - I am not sure what you mean here but we are certainly continuing to activiely develop on the RIO platform which includes FPGA as the key diffentiating technolgoy. If you take a look at the NI Week keynote videos (ni.com/niweek) there is no doubt from both Day 1 and Day 2 that FPGA will be an important well maintained platform for many years to come.

By Rick Kuhlman | LabVIEW FPGA Product Manager

Photodarkening

2010-12-21T16:38:00.001+09:00

Optical fiber splicing

2010-12-06T15:37:00.001+09:00

It is a nice website with informative contents in optical fiber splicing.
http://dar.ju.edu.jo/mansour/optical/Optical%20Fiber%20Splicing.htm
Go

IBM breakthrough could measure rapid changes to atoms

2010-09-24T08:51:00.000+09:00

By CNET

Efficiency of LabVIEW application

2010-09-16T19:59:00.002+09:00

Currently, I'm facing the problem of LabVIEW execution efficient. Thus, I found a book which simply can help my programming skills in LabVIEW and eventually can solve my problems. ^^

The following notes are written by P. A. Blume, The LabVIEW Style Book

An efficient LabVIEW application executes quickly, without performing unnecessary operations, particularly ones that are performed repeatedly within looping structures.
An efficient application also conserves memory by limiting the size of the four LabVIEW memory components: the front panel, block diagram, data space, and code.
Front panel and block diagram memory store the graphical objects and images that comprise the front panel and block diagram, respectively.
Data space memory contains all the data that flows through the diagram, as well as the diagram constants, default values for front panel controls, and the data that is copied when written to variables and front panel indicators.
Code is the portion of memory that contains the compiled source code.
Efficient applications minimize I/O operations, such as GUI updates, instrument and network communications, and data acquisition (DAQ) calls.
Execution speed and memory use are related.
Memory and disk operations are a principal source of latencies in all modern computing devices. As memory consumption grows during the execution of an application, LabVIEW's memory manager is called upon to allocate new and larger memory blocks. This causes a delay while the memory manager runs and results in fragmented memory, for which some of the previous blocks are not efficiently used. The memory manager is a wonderful aspect of LabVIEW that handles memory allocation automatically. However, developers should be aware of the types of operations that might cause it to run and avoid these situations from occurring unnecessarily.
Tools>>Profile>>Performance and Memory is directly measures the execution speed and data memory of all VIs loaded in memory. This tool helps to improve the efficiency of an application.
Use the Profile Performance and Memory window to determine which VIs consume the most time and memory, and examine those more closely. We can optimize our VI's efficiency by iteratively making improvements and checking the profile metrics.
The Profile Performance and Memory window is best used for measuring the change in efficiency of a single application when incremental modifications have been made.
An alternate method of evaluating efficiency is simply to inspect the application for sources of inefficiency.
Look for unnecessary operations within loops and for operations that create new data buffers. For example, contains many nodes within the main While Loop (includes read local variables, which make copies of their data when read from, and Property Nodes that are written within every iteration, regardless of whether their value has changed).
Tight loop is several control terminals are polled within the innermost While Loop as fast as the loop can run.
High-speed GUI polling is not an efficient use of the processor (most humans cannot distinguish between a 1 ms and a 100 ms GUI response).
More efficient alternatives include adding a delay using the Wait (ms) function or using an Event structure to service all user interface activity, and these alternatives free the processor to work on parallel tasks and applications.
Event structures are the most efficient method of capturing user interface activity.
Shift registers are much more efficient alternatives to variables, and queues are more much more functional.
Makes good used of sub VIs can increase memory efficiency, but uses sequence structures can decrease processing efficiency.
SubVis reduce the quantity of nodes on the diagram and reduces block diagram memory.
LabVIEW can reclaim memory buffers used by subVIs when the subVIs are not executing, thereby reducing data memory use.
Sequence structure is called, all frames must execute through completion, in consecutive order.

I will continue share the useful tips from this book since I'm reading it. I hope it is useful for you all too.

Design of Fiber Bragg Grating Acoustic Sensor for Structural Health Monitoring of Nuclear Power Plant

2010-09-14T14:54:00.003+09:00

Jung-Ryul Lee^1,^a See Yenn Chong^1,^b,Chang Yong Yun¹^,c,Hoon Sohn²^,^d

¹Dept. of Aerospace Engineering, Chonbuk National University, 664-14 Duckjin-dong, Duckjin-gu, Jeonju, Chonbuk, 561-756, Republic of Korea

²Dept. of Civil and Environmental Engineering, Korea Advanced Institute of Science and Technology, 335 Gwahangno, Yuseong-gu, Daejon, Korea

^aleejrr@jbnu.ac.kr, ^bchongandy@live.com, ^cchyun0207@nate.com, ^dhoonsohn@kaist.ac.kr

Keywords: Structural health monitoring, Nuclear power plant, Metal-coated optical fiber, Fiber Bragg grating acoustic sensor

Abstract. Nuclear power plant (NPP) is commonly categorized as a harsh environment that gives rise age-related degradation on the structures of plant and eventually leads to radiation leakage that threatens to human. Integrated structural health monitoring (ISHM) technology is a strong candidate for NPP accidents. The emergence of optical fiber technology into SHM system for NPP was greatly interested by researchers, and also prior research works have shown that the fiber Bragg grating (FBG) was able to retain its reflectivity under radiation exposure. In this paper, a metal-coated fiber was newly used to develop a FBG acoustic sensor for ISHM of NPP. The 7 mm length of aluminum, copper/carbon coatings were successfully removed with sodium hydroxide and nitric acid solutions. A 5 mm FBG was successfully inscribed in the silica core through the 7 mm long coating-removed silica section of copper/carbon-coated fiber and the initial reflectivity was 71%. Then, the FBG acoustic sensor was developed in one-end-free FBG configuration on the stainless steel vessel using a high temperature metallic adhesive. The reflective power of the sensor was stabilized at 345°C during the high temperature elevation cyclic process. The FBG acoustic sensor showed good response to the acousto-ultrasonic waves during pencil-lead breaking and laser ultrasounics tests. The high temperature FBG acoustic sensor written in the cost-effective metal/carbon is feasible to be used for ISHM of the NPP.

Note: The proceeding paper has published in Advanced Materials Research

A lasing wavelength stabilized simultaneous multipoint acoustic sensing system using pressure-coupled fiber Bragg gratings

2010-09-14T14:38:00.007+09:00

Jung-Ryul Lee^a^,^,, See Yenn Chong ^a, Chang-Yong Yun^a and Dong-Jin Yoon^b

^a Department of Aerospace Engineering, Chonbuk National University, 664-14 Duckjin-dong, Duckjin-gu, Jeonju, Chonbuk 561-756, Republic of Korea

^b Safety Measurement Center, Korea Research Institute of Standards and Science, 209 Gajeong-ro Yuseong-gu, Daejeon, Republic of Korea

Received 5 June 2010;

revised 17 July 2010;

accepted 15 August 2010.

Available online 30 August 2010.

Abstract

A fiber Bragg grating (FBG) sensor head, using a pressure coupling mechanism, was designed for broadband frequency response and structural strain-free characteristic. The pressure-coupled sensor heads were connected to a simultaneous multipoint acoustic sensing system based on a tunable laser. An intelligent lasing wavelength stabilization algorithm capable of identifying the direction of spectrum movement, the wavelength shifting speed, and a fiber bending event was developed so that the simultaneous multipoint acoustic sensing system could be used in environments with rapid temperature variations. The lasing wavelength feedback control algorithm updated the lasing wavelength into the steep slope of the FBG spectrum even under conditions of rapid temperature change. The averaging lasing wavelength updating time was only 21 s because the system can decide a minimal size in scan window by finding the FBG spectrum shifting speed and direction in real time. The system was able to update the lasing wavelength which missed the steep slope of the FBG spectrum under maximum temperature variation rates 0.3014 and −0.3246 °C/s. The proposed system detected simultaneous impact waves at multiple points under conditions of rapid temperature change and change in dynamic strain.

Keywords: Fiber Bragg grating; Tunable laser; Lasing wavelength stabilization; Integrated structural health management; Acoustic emission

Note: The journal paper has published in Optics and Lasers in Engineering (impact factor 1.262, 2010)

This is our future: Wireless electricity

2010-09-02T22:56:00.001+09:00

I’m back!!!

2009-09-05T16:14:00.001+09:00

That is very long did not update my blog due to my tight schedules on my holidays (with my wife at Malaysia and Seoul), research, and paper writing (the most headache).

Time passes very fast and it was already 1 year and 3 weeks staying in South Korea for my study. Now, I’m in my 2nd year Master’s degree course and the feeling is totally different as compared to my 1st year course.

LabVIEW State Machine Basic Example

2008-12-24T18:05:00.004+09:00

The following video clips are showing how we can use state machine method to control vending machine. By the way, I post this because I'm just starting to learn state machine for my research.... hehehe Thus, I would like to share with this examples which I found it very useful for beginner.

LabView State Based Machine Tutorial pt1 from LabView Tutorials on Vimeo.

LabView State Based Machine Tutorial pt 2 from LabView Tutorials on Vimeo.

LabView State Based Machine Tutorial pt 3 from LabView Tutorials on Vimeo.

LabView State Based Machine Tutorial pt 4 from LabView Tutorials on Vimeo.

LabView State Based Machine Tutorial pt 5 from LabView Tutorials on Vimeo.

LabView State Based Machine Tutorial pt6 from LabView Tutorials on Vimeo.

Hope it helps u...

Nice Quotes

2008-10-24T12:46:00.003+09:00

Nice Quotes (Unfortunately in Mandarin)

1. 你做的东西是不是都是你认为对的，却不一定是对的。

2. 是否是因为我们从未想过要放弃我们手中已经拥有的优势（车钥匙）? 有时，如果我们能放弃一些我们的固执，狭隘，和
一些优势的话，我们可能会得到更多。

3. 想改变世界，很难；要改变自己，则较为容易。
与其改变全世界，不如先改变自己--「将自己的双脚包起来」。
改变自己的某些观念和作法，以抵御外来的侵袭。
当自己改变后，眼中的世界自然也就跟着改变了。
如果你希望看到世界改变，那么第一个必须改变的就是自己。

4. 「心若改变，态度就会改变；态度改变，习惯就改变；习惯改变，人生就会改变。」

Nice Quotes from Albert Einstein

2008-09-08T20:04:00.010+09:00

They help me and wise my thoughts .... Are they help you also?

Try not to become a man of success but rather to become a man of value.

Truth is what stands the test of experience.

The secret to creativity is knowing how to hide your sources.

The important thing is not to stop questioning. Curiosity has its own reason for existing. One cannot help but be in awe when he contemplates the mysteries of eternity, of life, of the marvelous structure of reality. It is enough if one tries merely to comprehend a little of this mystery every day. Never lose a holy curiosity.

The important thing is not to stop questioning.

Reading, after a certain age, diverts the mind too much from its creative pursuits. Any man who reads too much and uses his own brain too little falls into lazy habits of thinking.

I never think of the future - it comes soon enough.

I believe in intuition and inspiration. Imagination is more important than knowledge. For knowledge is limited, whereas imagination embraces the entire world, stimulating progress, giving birth to evolution. It is, strictly speaking, a real factor in scientific research.

Equations are more important to me, because politics is for the present, but an equation is something for eternity.

If A is a success in life, then A equals x plus y plus z. Work is x; y is play; and z is keeping your mouth shut.

Albert Einstein

US (German-born) physicist (1879 - 1955)

Wish you all like it. Some times when I read it, it really make me feel better ans wise up my mind especially I face some problems in any things.