|
Are the images you have in the ImageList the same size as they are going to be displayed in? Or are they larger images being scaled down to icon size in your ListView? If they're being scaled, your sacrificing alot of image quality doing that. It's best to use images of the size they'll be rendered at, not scaled.
Dave Kreskowiak
Microsoft MVP - Visual Basic
|
|
|
|
|
I am calling "GetVolumeInformation" to get hold of drive volume label.
The 2nd parameter of this function is declared as
Dim driveLabel As String = Space(200)
This string remains 200 in length even though the label returned is only 11 chars long, say "MY PROJECTS "
This string delaration is giving me a lot of trouble and it completely messes up the rest of my code when I concat it with other string variables. (eg dim myText = " label is " & drivelabel). Everything become 200 in length.
Does anyone know how I can extract the useful part of "driveLabel" as declared above??? That is a string with the correct "string.length" value (for "MY PROJECT " I need driveLabel.length=10)
|
|
|
|
|
|
hi all i want to know ho to create the database though .net. i want when my application starts first time it create the databse there if it is not created. if i use the sql script then how to execute that script
Tasleem Arif
-- modified at 21:09 Saturday 17th June, 2006
|
|
|
|
|
|
Hello, can anybody tell me how to use the usb port. there is a lot of example to use the serial port COM. but I can't find any topic to use the USB port.
Thanks
OmarMallat
|
|
|
|
|
|
You didn't find anything because you don't use the USB port. You talk to the devices on it bu way of their drivers. What you need to do depends entirely on the device and why kind of API support the manufacturer gives you in the form of an SDK.
Dave Kreskowiak
Microsoft MVP - Visual Basic
|
|
|
|
|
Hi all. I have a DLL (VB.NET) which uses interop to write to a mailslot -- this is more or less like opening and writing to a file, and is not a problem.
This uses windows API CreateFile, gets a valid handle (no error, valid handle number), and immediately uses it in WriteFile. I have logging that shows the handle number I received from CreateFile is in fact still the same when the error occurs in WriteFile (and other than this logging, there's nothing between them).
Here's the problem:
It works if the DLL is in debug mode when compiled, and fails the WriteFile with "invalid handle" when in release mode. The host application is a simple test app in VB.NET which just creates the object this DLL exposes.
Here is the .NET code
lMailslotHandle = CreateFile(sMailSlot, GENERIC_WRITE, FILE_SHARE_READ, 0, OPEN_EXISTING, 0, 0)
If lMailslotHandle <> INVALID_HANDLE_VALUE Then
Try
lResult = WriteFile(lMailslotHandle, sMsg2, Len(sMsg2), lNumWritten, 0)
(and there's catch stuff here should any thrown error occur).
The above is enough to cause the problem! Any ideas? That is, lResult is zero and the value of Err.LastDllError is the error code for "handle is invalid".
The data being written is identical whether it is debug or release mode -- there is no code difference at all (in the application code -- obviously there is in the compiled code).
I suspect that I'm getting a wrong error message -- that the handle is not invalid, but that is just a suspicion.
Any ideas?
|
|
|
|
|
During your debugging, are you stopping the app between the time is creates the mailslot handle and the time where it's closed and released?? If not, you might want to try restarting the machine and going straight for the Release version.
The .NET CLR will NOT clean up unmanaged resources (like handles) for you and will leave them orphaned if you don't clean them up.
Dave Kreskowiak
Microsoft MVP - Visual Basic
|
|
|
|
|
The problem is not relating to debugging per se -- I am not actually running in the debugger at all -- I'm just moving the DLL to its run directory and running its host application. When I do that, the debug version works and the release version does not.
This is not a problem in clean up -- the problem is that I create the file then write (and by "file" I mean the mailslot handle), and the write fails with "invalid handle" only in the release version.
So I'm not stopping the code at all. Yes, I do understand about resource management, and in fact the whole thing is in a Try/Finally block with the Finally block handling the freeing of the resource. But that's not the problem, as the resource is not (and should not be) free at the time the write is done -- immediately after the CreateFile. But acts as if it is.
I hope that clarifies the issue a bit.
|
|
|
|
|
Hmmmm.... In that case, you'll have to add some code to call the Win32 GetLastError to find out why the handle was either not created or is considered invalid.
Dave Kreskowiak
Microsoft MVP - Visual Basic
|
|
|
|
|
That's what I do -- it is usually "invalid handle" at the WriteFile, and I've verified that the handle at that time is still identical to the handle just given by CreateFile.
Thanks,
Richard
|
|
|
|
|
Unless the types your using to Declare the functions aren't right, I have no idea what's going wrong. It could be because of optimizations done in the Release version that are not done in the Debug. I've never seen this problem, in Managed Code anyway. What do the Declares look like for CreateFile and whatever else you're using that's related.
Dave Kreskowiak
Microsoft MVP - Visual Basic
-- modified at 7:25 Monday 19th June, 2006
|
|
|
|
|
Believe me, it makes no sense to me either, other than as a compiler or linker bug. Here's the declares:
Public Declare Function CreateFile Lib "kernel32" Alias "CreateFileA" _
(ByVal lpFilename As String, ByVal dwDesiredAccess As Int32, _
ByVal dwShareMode As Int32, ByVal lpSecurityAttributes As Int32, _
ByVal dwCreationDisposition As Int32, ByVal dwFlagsAndAttributes As Int32, _
ByVal hTemplateFile As Int32) As Int32
Private Declare Function WriteFile Lib "kernel32" (ByVal hFile As Int32, ByVal lpBuffer As String, ByVal nNumberOfBytesToWrite As Int32, _
ByRef lpNumberOfBytesWritten As Int32, ByRef lpOverlapped As Int32) As Int32
Private Const GENERIC_WRITE As Int32 = &H40000000
Here's the two calls:
Dim lMailslotHandle As Int32
Dim lResult As Int32
Dim lNumWritten As Int32
lMailslotHandle = CreateFile(sMailSlot, GENERIC_WRITE, FILE_SHARE_READ, 0, OPEN_EXISTING, 0, 0)
lResult = WriteFile(lMailslotHandle, sMsg2, Len(sMsg2), lNumWritten, 0)
Private Const FILE_SHARE_READ As Int32 = &H1
Note that for mailslots, one MUST use FILE_SHARE_READ in CreateFile.
The error in release mode is typically "invalid handle" on the Writefile. Here's a bit more. If I run the release version form the IDE (i.e. in debug mode, but not debug compile) it does not give the error, and works fine. Perhaps that really uses debug mode.
There's more weirdness. The DLL that contains this is supposed to be called via COM, and I have the appropriate COM registration for this. I have two test programs for the DLL -- one in .NET, one in VB6, more or less identical. However, when called from COM (i.e. a VB6 app), the debug version ALSO fails with invalid handle, but succeeds when called from .NET. To make it worse (better?) all I do to test is create an instance of the DLL object, as all this happens in the New() method -- so there isn't any problem in argument or result marshalling to account for this. In all cases (working or failure), logging shows the handle from CreateFile is still intact at the time WriteFile fails.
|
|
|
|
|
Wow, I can tell that the wrong types are being used. Int32 is a signed type, which is not the best for handling bit flags and handles. Instead, you might want to pass those flags as Enums using a base type of UInt32 and the handle values should be stored and passed as IntPtr's. You can find the CreateFile declaration here[^] on Pinvoke.net. There are also listings for the proper enums for the bit flags.
rberman wrote: If I run the release version form the IDE (i.e. in debug mode, but not debug compile)
If the solution configuration selected as Release or Debug? If Debug, the IDE will run the Debug compiled code, not the release. If you run the Release version from in the IDE, by default, you'll get a warning box that says something like "Whatever module was built with optimizations or without debug information... yada yada yada". The debugger won't be able to stop the code with breakpoints if this is the case. If you can stop the code, then you're running the Debug version.
Dave Kreskowiak
Microsoft MVP - Visual Basic
|
|
|
|
|
Dave -- that's what I'd think, but I definitely select "release", get no warning, and breakpoints work -- sort of. The program data will be from the last Debug compilation, and so if I've added or removed any lines, the breakpoints will be off. This seems to indicate it really does allow the release mode to work in the debugger -- or it doesn't rebuild the PDB data (and file dates seem to indicate it did rebuild release version in this case).
Go figure. Anyway, it is incidental to the issue.
Thanks for the info on the declarations -- will definitely check them out and let you know.
|
|
|
|
|
rberman wrote: but I definitely select "release", get no warning, and breakpoints work
Then you're either running the Debug code or you've changed the Project's Configuration options and told the Release configuration to generate debug database when compiled.
Dave Kreskowiak
Microsoft MVP - Visual Basic
|
|
|
|
|
Well.... I think they are incorrect to have IntPtr as the return type -- a handle is NOT a pointer -- it is a system assigned integer used to identify an object. From the application perspective, it IS an integer, and in fact that is the way the API is used in any C program. The only restriction is on whether the handle can be inherited by another task (which requires a security descriptor attached when the handle is created).
Garbage collection should have no impact on handles therefore -- they are a simple identifier, not an address that might be moved in garbage collection.
So now I'm curious why they treat it this way -- is there something else that .NET does to system-assigned handles that might make them susceptible to damage?
|
|
|
|
|
rberman wrote: a handle is NOT a pointer
No. A handle is an unsigned integer the width of the address bus on the machine. So, if you run your code on a 64-bit machine, you'll get handles that are 64-bits wide. This is why it's not a good idea to specify handles as Interger or Int32. They're the same, a signed 32-bit integer, no matter what platform they're running on. So, on a 64-bit machine you'll be trying to stuff a 64-bit handle into a 32-bit space. Not going to happen...
IntPtr's are system-width, no matter what platform they're running on. You don't have to recode your app at all to switch between 32-bit and 64-bit.
rberman wrote: Garbage collection should have no impact on handles therefore -- they are a simple identifier, not an address that might be moved in garbage collection.
Partially correct. Garbage collection will not touch unmanaged handles at all. But, there is a finite number of them that are "checked-out" from the system and are assigned an ID number. If that handle isn't specifically freed, it will never be returned to the pool, and you'll eventually run the system out of handles.
rberman wrote: So now I'm curious why they treat it this way -- is there something else that .NET does to system-assigned handles that might make them susceptible to damage?
Nope. Nothing. The problem comes in when the handle is not marshalled to Managed code properly, like using the wrong managed type to store it.
Dave Kreskowiak
Microsoft MVP - Visual Basic
|
|
|
|
|
OK -- changing these handles to IntPtrs had one interesting difference -- First, a quick summary so this makes sense:
When called from .NET host, the DLL routine worked both in debug and release mode. When called from a COM host, both failed (invalid handle).
With IntPtr... Debug mode compilation works for BOTH .NET and COM hosts, and release-mode compilation FAILS for both! So this is really a net-zero gain if one were keeping score. But, I CAN use the debug-compiled version for production, so if this ends up working on the test and production systems, it will at least be a go.
But it still looks like something rather seriously wrong with the compiler. I see .NET 2.0 has a "safe handle" object, so apparently there IS something dicey about using handles in .NET 1.1
|
|
|
|
|
rberman wrote: But it still looks like something rather seriously wrong with the compiler.
Nope. I've used CreateFile/WriteFile, P/Invoked in .NET 1.0, 1.1 and 2.0, both Release and Debug configurations, with no problems whatsoever. Well, other than my own boneheaded mistakes. 
Dave Kreskowiak
Microsoft MVP - Visual Basic
|
|
|
|
|
Hi, I need help to do a source code using visual studio2005.net to do a barchart which has the x-axis for id of people and the co,mmunication error rate. Thanks!
Eric
-- modified at 5:29 Saturday 17th June, 2006
|
|
|
|
|
Help!
I migrated a program from Vb6.0 to VB.NET and I have this line of code:
iRetVal = CopyFileEx(lszNetFile, lszSys32File, AddressOf CopyProgressRoutine, 0, bCancel, COPY_FILE_RESTARTABLE)
which unfortunately generates the following error:
'AddressOf' expression cannot be converted to 'Integer' because 'Integer' is not a delegate type.
What must I do? HELP!!!
Thanks,
MAY
|
|
|
|
|
You've got the Declare for the CopyFileEx function wrong. It should be:
Declare Auto Function CopyFileEx Lib "kernel32" ( _
ByVal lpExistingFilename As String, _
ByVal lpNewFilename As String, _
ByVal lpCopyProgressRoutine As CopyProgressRoutineDelegate, _
ByVal lpData As IntPtr, _
ByRef pCancel As Boolean, _
ByVal dwCopyFlags As CopyFlags)
You can find the definitions for the CopyProgressRoutineDelegate and CopyFile enum at www.pinvoke.net[^]
Dave Kreskowiak
Microsoft MVP - Visual Basic
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
