|
You didn't answer my question...
What do you mean by "some times it take a long time to recive email"?? Are you running your own mail server at home? Are you expecting a message from an outside sender to be delivered to your mail server and you're not receiving it? Or are you saying that the mail message never leaves your mail server and arrives at its destination?
By the IP address in your code, I'll assume that your running a mail server on your local machine. Most ISP's will NOT allow this and will NOT forward messages sent from unauthorized mail servers.
Dave Kreskowiak
Microsoft MVP - Visual Basic
|
|
|
|
|
hellow ,
i am only trying to send to outers emails ,
i am not trying to recive ,
and some times i recive this message could not access CDO.Message object ,
how can i do this ?
-- modified at 8:19 Tuesday 20th June, 2006
|
|
|
|
|
Change the SmtpServer IP Address to that of your ISP's SMTP server.
Dave Kreskowiak
Microsoft MVP - Visual Basic
|
|
|
|
|
i did is there anything else that i have to do ?
|
|
|
|
|
That depends on your ISP's SMTP server. But, generally, no, there isn't.
As for the CDO.Message object error, you might want to take a look at this[^].
Dave Kreskowiak
Microsoft MVP - Visual Basic
|
|
|
|
|
hi Friend,
can u show or email ur code to me!!
I also work on that!!
my address is "rahulshendurnikar@gmail.com"bbye
Rahul here
|
|
|
|
|
I add some picture to imagelist, the imagewidth and imageheight property has been set.
Then show them in a listview by icon view mode.
However, the picture is not clear.
How to do?
Thanks!
VB 6.0
|
|
|
|
|
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
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
