.NET (Core and Framework)

19-Aug-07 8:13

myDateTimePicker.Value.DayOfWeek.ToString()
or
myDateTimePicker.Value.ToString("ddd")
or
myDateTimePicker.Value.ToString("ddddddddddd")

Luc Pattyn [Forum Guidelines] [My Articles]

this weeks tips:
- make Visual display line numbers: Tools/Options/TextEditor/...
- show exceptions with ToString() to see all information
- before you ask a question here, search CodeProject, then Google

messenger

volvoline17-Aug-07 8:49

volvoline

17-Aug-07 8:49

How can i build a messenger in .net? with id and password stored in server Confused | :confused:

Re: messenger

originSH19-Aug-07 1:04

originSH

19-Aug-07 1:04

Decide how to store the ID and password. Write the code to access the IDs and passwords.

Decide the transport method and protocol for the messenging. Write the code to use that transport methd and protocol.

If you want more details there are plenty of tutorials you can search for on google.

If you have any specific problems, rather than generals ones then just ask and we'll be happy to help.

Framework Version

jchigg200017-Aug-07 7:10

jchigg2000

17-Aug-07 7:10

Hi Guys

Is there a place in visual studio to select which version of the framework you'd like to use for a specific project?

Luc Pattyn17-Aug-07 7:31

17-Aug-07 7:31

Studio 2003 targets 1.1 only
Studio 2005 targets 2.0 only (and 3.x which are just extensions)
AFAIK Orcas lets you choose exactly which >=2.0 you will target

Smile | :)

Luc Pattyn [Forum Guidelines] [My Articles]

Scott Dorman17-Aug-07 7:41

Scott Dorman

17-Aug-07 7:41

Luc Pattyn wrote:
AFAIK Orcas lets you choose exactly which >=2.0 you will target

Yes, that is the case. The default for new projects is .NET Framework 3.5, but you can change it as needed to 3.0 or 2.0.

-----------------------------
In just two days, tomorrow will be yesterday.

http://geekswithblogs.net/sdorman

Scott Dorman17-Aug-07 7:48

Scott Dorman

17-Aug-07 7:48

Not until Visual Studio 2008 is released, unless you want to use the Beta 2 release.

Visual Studio Version                        .NET Framework Version
--------------------------------------------------------------------
Visual Studio.NET                              1.0
Visual Studio 2003                             1.1
Visual Studio 2005                             2.0
Visual Studio 2005 with .NET 3.0 Extensions    3.0
Visual Studio 2008                             3.5, 3.0, 2.0

-----------------------------
In just two days, tomorrow will be yesterday.

http://geekswithblogs.net/sdorman

jchigg200017-Aug-07 7:58

jchigg2000

17-Aug-07 7:58

Thanks for the info guys. I found what I was looking for under

Project -> Properties -> Build -> Change Button

Vasudevan Deepak Kumar20-Aug-07 20:36

Vasudevan Deepak Kumar

20-Aug-07 20:36

Visual Studio 2005 has a Version Selector component right?

Vasudevan Deepak Kumar
Personal Homepage
Tech Gossips

64-bit Interop

Leslie Sanford17-Aug-07 6:42

17-Aug-07 6:42

I was running one of my assemblies through FxCop and got this message:

"As it is declared in your code, parameter 'handle' of PInvoke NativeMethods.waveOutGetVolume(Int32, Int32&):Int32 will be 4 bytes wide on 64-bit platforms. This is not correct, as the actual native declaration of this API indicates it should be 8 bytes wide on 64-bit platforms. Consult the MSDN Platform SDK documentation for help determining what data type should be used instead of 'System.Int32'."

I've been looking at MSDN and haven't found anything yet specific to this problem. Still looking. But I thought I'd go ahead and ask here. How do you declare your interop methods so that they work correctly on both 32-bit and 64-bit systems?

Re: 64-bit Interop [modified]

Abisodun17-Aug-07 6:49

Abisodun

17-Aug-07 6:49

Use IntPtr in place of Int32.

Leslie Sanford17-Aug-07 7:23

17-Aug-07 7:23

Abisodun wrote:
Use IntPtr in place of Int32.

But does this mean having to allocate unmanaged memory for the pointer?

If I do this:

IntPtr handle = new IntPtr();
 
int result = waveOutOpen(handle, deviceID, ref format, 0, 0, CALLBACK_NULL);

waveOutOpen returns an error.

If I have to allocate unmanaged memory for the pointer (ugh), how do I tell how much to allocate? On a 32-bit system it will be 4 bytes. On a 64-bit system it will be 8 bytes.

[EDIT]

Nevermind. I discovered that I need to declare my interop method like this:

[DllImport("winmm.dll")]
public static extern int waveOutOpen(out IntPtr handle, int deviceID, ref WaveFormat format, 
    int dummy, int instance, int flags);

The key is to use the out modifier on the IntPtr parameter.

Thanks for your help. Smile | :)

[/EDIT]

-- modified at 13:34 Friday 17th August, 2007

Dave Kreskowiak17-Aug-07 7:35

Dave Kreskowiak

17-Aug-07 7:35

The size of IntPtr changes depending on the proc. So, an IntPtr on a 32-bit system is 32-bits wide and on a 64-bit system is 64-bits wide, automatically.

You don't have to allocate anything. You're just using the pointer as a self-sizing integer.

IntPtr handle = IntPtr.Zero;

A guide to posting questions on CodeProject[^]

Dave Kreskowiak
Microsoft MVP
Visual Developer - Visual Basic
2006, 2007

Leslie Sanford17-Aug-07 7:38

17-Aug-07 7:38

Dave Kreskowiak wrote:
The size of IntPtr changes depending on the proc. So, an IntPtr on a 32-bit system is 32-bits wide and on a 64-bit system is 64-bits wide, automatically.

You don't have al allocate anything. You're just using the pointer as a self-sizing integer.

Understood. I think I was running into problems when I tried switching to IntPtr because I was using the ref modifier on the IntPtr parameter instead of out.

Thanks for your help.

Luc Pattyn17-Aug-07 7:38

17-Aug-07 7:38

Hi Leslie,

here is my theory (still theory since I have not run any of this on Win64):
- for native pointers you really should use IntPtr, and it is not hard to do so.
- Win32 uses 4B pointers, Win64 needs 8B pointers
- you must build for either 32-bit or 64-bit
- on Win64 everything must be consistent (all modules 64-bit is fine, and
all modules 32-bit runs in some compatibility mode, not sure tho)
- IntPtr is a value type that holds either 4B or 8B pointer value
- IntPtr must be initialized, normally you give its value at construction
- a lot of P/Invoke examples are wrong, and use int/uint where it should have
been IntPtr. Most notably SendMessage: lParam, wParam and return value should
be regarded as IntPtr, and cast to int or whatever if and when appropriate.
- correct prototypes would have IntPtr for anything that is or could be a handle
(such as lParam).

Your problem seems to be you did not initialize handle.

Smile | :)

Luc Pattyn [Forum Guidelines] [My Articles]

Leslie Sanford17-Aug-07 7:42

17-Aug-07 7:42

Luc Pattyn wrote:
here is my theory (still theory since I have not run any of this on Win64):
- for native pointers you really should use IntPtr, and it is not hard to do so.
- Win32 uses 4B pointers, Win64 needs 8B pointers
- you must build for either 32-bit or 64-bit
- on Win64 everything must be consistent (all modules 64-bit is fine, and
all modules 32-bit runs in some compatibility mode, not sure tho)
- IntPtr is a value type that holds either 4B or 8B pointer value
- IntPtr must be initialized, normally you give its value at construction
- a lot of P/Invoke examples are wrong, and use int/uint where it should have
been IntPtr. Most notably SendMessage: lParam, wParam and return value should
be regarded as IntPtr, and cast to int or whatever if and when appropriate.
- correct prototypes would have IntPtr for anything that is or could be a handle
(such as lParam).

Thanks for this explanation.

I've got a lot of code revision to do. I have older "toolkits" whose P/Invoke methods are apparently wrong, or will at least break on a 64-bit system.

Luc Pattyn wrote:
Your problem seems to be you did not initialize handle.

Actually, I don't think I'm suppose to initialize the handle, rather I should use the out modifier on the IntPtr parameters rather than ref, as I had initially tried.

Luc Pattyn17-Aug-07 7:47

17-Aug-07 7:47

Leslie Sanford wrote:
Actually, I don't think I'm suppose to initialize the handle, rather I should use the out modifier on the IntPtr parameters rather than ref, as I had initially tried

That depends entirely on the function at hand; you typically need to provide
an IntPtr or be ready to receive one (with "out" keyword).

I don't recall any Win32 function that provides a handle that way, they typically
use the return value (and return zero for error, then you would call GetLastError
for details).

Greetings

Luc Pattyn [Forum Guidelines] [My Articles]

Leslie Sanford17-Aug-07 8:04

17-Aug-07 8:04

Luc Pattyn wrote:
That depends entirely on the function at hand; you typically need to provide
an IntPtr or be ready to receive one (with "out" keyword).

I don't recall any Win32 function that provides a handle that way, they typically
use the return value (and return zero for error, then you would call GetLastError
for details).

Oh, I wasn't clear. The example I gave in my earlier post was with waveOutOpen; it opens a waveform output device. The native version takes an pointer to a WAVEOUT handle and returns a MMRESULT value indicating the status of the operation. If the operation was successful, the handle is filled with a valid handle to the device. This handle is later used with other waveOutXXX functions to interact with the device.

So in this specific case, I needed an unitialized IntPtr to pass as the handle modified by the out keyword.

After the wave device has been opened, other waveOutXXX functions that are called expect the handle to be initialized.

Does this make sense?

Luc Pattyn17-Aug-07 8:14

17-Aug-07 8:14

Leslie Sanford wrote:
Does this make sense?

Of course, it does.

I was not familiar with waveOutOpen, but I looked it up now, and you are right,
it does output a handle, hence "out someIntPtr" is the right way to go.

The only comment I could make is you don't need the "=new IntPtr()" part of
your handle declaration, a simple "IntPtr handle;" should suffice.

Smile | :)

Luc Pattyn [Forum Guidelines] [My Articles]

Leslie Sanford17-Aug-07 11:30