|
Following the discussion I had with Luc, I've done some investigation into the way uinions work, and he is correct, the parameters inside the union block start at the same place in memory - in otherwords, the struct will contain one of the handles but not both so the best way to declare it is:
[StructLayout(LayoutKind.Sequential)]
private struct LINEINITIALIZEEXPARAMS
{
public uint dwTotalSize;
public uint dwNeededSize;
public uint dwUsedSize;
public uint dwOptions;
public IntPtr handle;
public uint dwCompletionKey;
}
|
|
|
|
|
I'm glad to see your answer. But now I meet a new problem, that I can't get HINSTANCE. I had find some ways in MSDN. But no available way I found. Could you be kind to help me again? Thank you!
There is some white cloud floating on the blue sky. That's the landscape I like.
modified on Monday, September 13, 2010 2:03 AM
|
|
|
|
|
MSDN says: "Instance handle of the client application or DLL. The application or DLL can pass NULL for this parameter, in which case TAPI uses the module handle of the root executable of the process (for purposes of identifying call handoff targets and media mode priorities).
The clue is "can pass NULL", which in the case of PInvoke handles is IntPtr.Zero . That should work.
If not, have a look at the Process.Handle[^] property - perhaps this will work?
IntPtr hInstance = System.Diagnostics.Process.GetCurrentProcess().Handle;
and pass hInstance as the parameter..., I prefer IntPtr.Zero though!
|
|
|
|
|
I had tested the code above. I feel sorry that it can't work. Because I am developing application for Windows Mobile. The property System.Diagnostics.Process.GetCurrentProcess().Handle can't be get in Mobile. I had try to give hInstance with the value of new IntPtr(GetModuleHandle(new IntPtr(0)).ToInt32()) . But when I call lineInitializeEx with it, the return value is an error code. That tell me the value of handle is invalid(0x80000035). Base of all, I think I can't call lineInitializeEx with C# at all. Isn't it?
There is some white cloud floating on the blue sky. That's the landscape I like.
|
|
|
|
|
Have you tried with IntPtr.Zero or new IntPtr(0)
What is the error code? It should be one of these:
public const uint LINEERR_NOERROR = 0x00000000;
public const uint LINEERR_INVALAPPNAME = 0x80000015;
public const uint LINEERR_INIFILECORRUPT = 0x8000000E;
public const uint LINEERR_INVALPARAM = 0x80000032;
public const uint LINEERR_INVALPOINTER = 0x80000035;
public const uint LINEERR_NOMEM = 0x80000044;
public const uint LINEERR_OPERATIONFAILED = 0x80000048;
public const uint LINEERR_REINIT = 0x80000052;
If the version of WinMob you're targetting supports TAPI then it will work once you get it just right!
Maybe post your lineInitializeEx and LINEINITIALIZEEXPARAMS ...
|
|
|
|
|
I had try to use the value of IntPtr.Zero and new IntPtr(0) before. The return value is error too. In all cases, the error code returned is still public const uint LINEERR_INVALPOINTER = 0x80000035; . I am sure my Window Mobile support TAPI. I had developed a TAPI application with C++. Thank you!
There is some white cloud floating on the blue sky. That's the landscape I like.
|
|
|
|
|
Can you post your function and struct declarations?
|
|
|
|
|
public bool OpenLine()
{
UInt32 dwDevNum = 0;
UInt32 dwApiVerSion = TAPI_CURRENT_VERSION;
LINEINITIALIZEEXPARAMS dtParams = new LINEINITIALIZEEXPARAMS();
dtParams.dwTotalSize = (UInt32)Marshal.SizeOf(dtParams);
dtParams.dwOptions = 1;
IntPtr handles = new IntPtr(0);
IntPtr hInstance = IntPtr.Zero;
unsafe
{
fixed(IntPtr *hLineApp = &m_hLineApp)
{
long lResult = lineInitializeEx(hLineApp, hInstance, new IntPtr(0), new IntPtr(0),
new IntPtr(&dwDevNum), new IntPtr(&dwApiVerSion), new IntPtr(&dtParams));
if (lResult == 0)
{
return true;
}
}
return false;
}
}
[StructLayout(LayoutKind.Sequential)]
private struct LINEINITIALIZEEXPARAMS
{
public uint dwTotalSize;
public uint dwNeededSize;
public uint dwUsedSize;
public uint dwOptions;
public IntPtr hMultiUse;
public uint dwCompletionKey;
}
[DllImport("coredll.dll", SetLastError = true)]
unsafe private static extern uint lineInitializeEx(
IntPtr *lphLineApp,
IntPtr hInstance,
IntPtr pfnCallback,
IntPtr FriendAppName,
IntPtr pNumDevs,
IntPtr pAPIVersion,
IntPtr pLineInitializeExParams);
There is some white cloud floating on the blue sky. That's the landscape I like.
|
|
|
|
|
Not too sure where the problem is. The first thing I'd do is get rid of the *, &, unsafe and fixed pointer stuff.
It's rarely needed as the built in marshaller can handle this stuff way better. I doubt it's the cause of your problems but declaring dwDevNum and creating a pointer from it's address is not going to work.
There are two keywords for passing value types by reference (thier pointer), ref and out .
If a value needs to be passed into a function then use ref . If the function doesn't need a value but there will be one there after the function returns then use out . In the case of dwDevNum this should be out but lpdwAPIVersion and dtParams should be ref . As IntPtr is a value type the pointer to a pointer for lphLineApp can be done using ref /out as well.
To the solution... have a look at this[^]. The guy says his C# code works.
|
|
|
|
|
I will study the code you provided. Thank you!
There is some white cloud floating on the blue sky. That's the landscape I like.
|
|
|
|
|
Dear all
I've got an issue with a COM interface I'm writing. I have to pass an array of c# objects back to VBScript and when I do I'm getting object required errors.
The com interface works like this
[ComVisible(true)]
public void findPatients(ref object MatchedPatients) {
List<object> mpList = retrievePatientList();
int arraySize = mpList.Count;
MatchedPatients = new object[arraySize];
MatchedPatients = mpList.ToArray();
}
The patient object is just a list of strings, i.e.
public class patientObject {
public string Key;
public string Surname;
public string Forename;
....
}
The COM interface is called by the following VBScript
dim j
o.findPatients j
Dim sOutput
sOutput = ""
For Each oPatient in j
' Code fails on the next line
sOutput = sOutput & oPatient.Surname
....
Next
If I step through the VBScript, variable j is getting assigned as an array of variants, the variable oPatient is assigned as an Object, but when I try and access any of the values within oPatient I'm getting an Object required error.
If anyone can offer any guidance it would be most appreciated, I'm tearing my hair out over this one.
UPDATE
I've fixed this issue now, it was surprisingly simple. All I had to do was make my object (PatientObject above) ComVisible and then VBScript could see the properties.
TO make a prairie it takes a clover and one bee,—
One clover, and a bee,
And revery.
The revery alone will do
If bees are few.
Emily Dickinson
modified on Tuesday, September 14, 2010 7:15 AM
|
|
|
|
|
Hi,
Is there a rather simple and constructive ways of validating a string value against a bunch value?
For example,
If I have a variable called "strStatus" it should only hold "In-Progress", "Closed" or "Open".
I know that I can do this using simple if condition or linq. Is there any other ways, like using enum etc.
Jack Sparrow
--------------------------------------
Defeat is not the worst of failures. Not to have tried is the true failure.
|
|
|
|
|
If the variable is only allowed to hold certain set of values, I wouldn't use string at all... An enum is the way to go. Enums can be converted to string easily and you can also parse a string to get the corresponding enum value.
If, for some reason you really need to use a string, there are several ways to validate it. Using a regular expression might be a good way to do it...
|
|
|
|
|
Yes an Enum should do the trick.
Jack Sparrow
--------------------------------------
Defeat is not the worst of failures. Not to have tried is the true failure.
|
|
|
|
|
To add to that, have a look atTips: Human readable strings for enum elements[^] which will let you use "In-Progress" as the string for the enum (normally you can't as enum elements must conform to normal C# variable name rules)
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
|
|
|
|
|
|
Hi all,
I am developing a winform application.This application has several (approx. 45) windows with custom rendering on it.
I am also using a third party tool for docking and undocking these windows.
When I play with all these windows (like docking undocking and moving them from thier location etc) very rarely I face this issue of an 'Application.OnThreadException'.
The custom rendering of all windows is heavy process.
Following A) is Exception and B) is the Stack trace I got once the exception has occured.
This issue is very hard to reproduce but it is there for sure.
Could you please guide me regarding any possible reason for the same?
Thanks in advance!
A) ---Exception Message ---
Object reference not set to an instance of an object.
B) ----Stack Trace---
System.Windows.Forms.dll!System.Windows.Forms.Application.ThreadContext.OnThreadException(System.Exception t) + 0x8b bytes
System.Windows.Forms.dll!System.Windows.Forms.Control.WndProcException(System.Exception e) + 0x16 bytes
System.Windows.Forms.dll!System.Windows.Forms.Control.ControlNativeWindow.OnThreadException(System.Exception e) + 0xc bytes
System.Windows.Forms.dll!System.Windows.Forms.NativeWindow.Callback(System.IntPtr hWnd, int msg = 562, System.IntPtr wparam, System.IntPtr lparam) + 0x72 bytes
System.Windows.Forms.dll!System.Windows.Forms.NativeWindow.DefWndProc(ref System.Windows.Forms.Message m = {msg=0x232 (WM_EXITSIZEMOVE) hwnd=0xa0cbc wparam=0x0 lparam=0x0 result=0x0}) + 0x130 bytes
System.Windows.Forms.dll!System.Windows.Forms.NativeWindow.WndProc(ref System.Windows.Forms.Message m) + 0x5 bytes
Syncfusion.Tools.Windows.dll!Syncfusion.Windows.Forms.Tools.NotifyNativeWindow.WndProc(ref System.Windows.Forms.Message m = {msg=0x232 (WM_EXITSIZEMOVE) hwnd=0xa0cbc wparam=0x0 lparam=0x0 result=0x0}) + 0xb3 bytes
System.Windows.Forms.dll!System.Windows.Forms.NativeWindow.DebuggableCallback(System.IntPtr hWnd, int msg = 562, System.IntPtr wparam, System.IntPtr lparam) + 0x57 bytes
[Native to Managed Transition]
System.Windows.Forms.dll!System.Windows.Forms.NativeWindow.DefWndProc(ref System.Windows.Forms.Message m = {msg=0x112 (WM_SYSCOMMAND) hwnd=0xa0cbc wparam=0xf012 lparam=0x10f0494 result=0x0}) + 0x93 bytes
System.Windows.Forms.dll!System.Windows.Forms.Form.DefWndProc(ref System.Windows.Forms.Message m) + 0x89 bytes
System.Windows.Forms.dll!System.Windows.Forms.Control.WndProc(ref System.Windows.Forms.Message m) + 0x40a bytes
System.Windows.Forms.dll!System.Windows.Forms.ScrollableControl.WndProc(ref System.Windows.Forms.Message m) + 0x2a bytes
System.Windows.Forms.dll!System.Windows.Forms.ContainerControl.WndProc(ref System.Windows.Forms.Message m) + 0x10 bytes
System.Windows.Forms.dll!System.Windows.Forms.Form.WmSysCommand(ref System.Windows.Forms.Message m) + 0x70 bytes
System.Windows.Forms.dll!System.Windows.Forms.Form.WndProc(ref System.Windows.Forms.Message m) + 0x1ec bytes
Syncfusion.Tools.Windows.dll!Syncfusion.Windows.Forms.Tools.FloatingForm.WndProc(ref System.Windows.Forms.Message msg = {msg=0x112 (WM_SYSCOMMAND) hwnd=0xa0cbc wparam=0xf012 lparam=0x10f0494 result=0x0}) + 0x22b5 bytes
System.Windows.Forms.dll!System.Windows.Forms.Control.ControlNativeWindow.OnMessage(ref System.Windows.Forms.Message m) + 0x10 bytes
System.Windows.Forms.dll!System.Windows.Forms.Control.ControlNativeWindow.WndProc(ref System.Windows.Forms.Message m) + 0x31 bytes
System.Windows.Forms.dll!System.Windows.Forms.NativeWindow.Callback(System.IntPtr hWnd, int msg = 274, System.IntPtr wparam, System.IntPtr lparam) + 0x5a bytes
System.Windows.Forms.dll!System.Windows.Forms.NativeWindow.DefWndProc(ref System.Windows.Forms.Message m = {msg=0x112 (WM_SYSCOMMAND) hwnd=0xa0cbc wparam=0xf012 lparam=0x10f0494 result=0x0}) + 0x130 bytes
System.Windows.Forms.dll!System.Windows.Forms.NativeWindow.WndProc(ref System.Windows.Forms.Message m) + 0x5 bytes
Syncfusion.Tools.Windows.dll!Syncfusion.Windows.Forms.Tools.NotifyNativeWindow.WndProc(ref System.Windows.Forms.Message m = {msg=0x112 (WM_SYSCOMMAND) hwnd=0xa0cbc wparam=0xf012 lparam=0x10f0494 result=0x0}) + 0xb3 bytes
System.Windows.Forms.dll!System.Windows.Forms.NativeWindow.DebuggableCallback(System.IntPtr hWnd, int msg = 274, System.IntPtr wparam, System.IntPtr lparam) + 0x57 bytes
[Native to Managed Transition]
System.Windows.Forms.dll!System.Windows.Forms.NativeWindow.DefWndProc(ref System.Windows.Forms.Message m = {msg=0xa1 (WM_NCLBUTTONDOWN) hwnd=0xa0cbc wparam=0x2 lparam=0x10f0494 result=0x0}) + 0x93 bytes
System.Windows.Forms.dll!System.Windows.Forms.Form.DefWndProc(ref System.Windows.Forms.Message m) + 0x89 bytes
System.Windows.Forms.dll!System.Windows.Forms.Control.WndProc(ref System.Windows.Forms.Message m) + 0x10e bytes
System.Windows.Forms.dll!System.Windows.Forms.ScrollableControl.WndProc(ref System.Windows.Forms.Message m) + 0x2a bytes
System.Windows.Forms.dll!System.Windows.Forms.ContainerControl.WndProc(ref System.Windows.Forms.Message m) + 0x10 bytes
System.Windows.Forms.dll!System.Windows.Forms.Form.WmNcButtonDown(ref System.Windows.Forms.Message m) + 0x29 bytes
System.Windows.Forms.dll!System.Windows.Forms.Form.WndProc(ref System.Windows.Forms.Message m) + 0x1de bytes
Syncfusion.Tools.Windows.dll!Syncfusion.Windows.Forms.Tools.FloatingForm.WndProc(ref System.Windows.Forms.Message msg = {msg=0xa1 (WM_NCLBUTTONDOWN) hwnd=0xa0cbc wparam=0x2 lparam=0x10f0494 result=0x0}) + 0x1f53 bytes
System.Windows.Forms.dll!System.Windows.Forms.Control.ControlNativeWindow.OnMessage(ref System.Windows.Forms.Message m) + 0x10 bytes
System.Windows.Forms.dll!System.Windows.Forms.Control.ControlNativeWindow.WndProc(ref System.Windows.Forms.Message m) + 0x31 bytes
System.Windows.Forms.dll!System.Windows.Forms.NativeWindow.Callback(System.IntPtr hWnd, int msg = 161, System.IntPtr wparam, System.IntPtr lparam) + 0x5a bytes
System.Windows.Forms.dll!System.Windows.Forms.NativeWindow.DefWndProc(ref System.Windows.Forms.Message m = {msg=0xa1 (WM_NCLBUTTONDOWN) hwnd=0xa0cbc wparam=0x2 lparam=0x10f0494 result=0x0}) + 0x130 bytes
System.Windows.Forms.dll!System.Windows.Forms.NativeWindow.WndProc(ref System.Windows.Forms.Message m) + 0x5 bytes
Syncfusion.Tools.Windows.dll!Syncfusion.Windows.Forms.Tools.NotifyNativeWindow.WndProc(ref System.Windows.Forms.Message m = {msg=0xa1 (WM_NCLBUTTONDOWN) hwnd=0xa0cbc wparam=0x2 lparam=0x10f0494 result=0x0}) + 0xb3 bytes
System.Windows.Forms.dll!System.Windows.Forms.NativeWindow.DebuggableCallback(System.IntPtr hWnd, int msg = 161, System.IntPtr wparam, System.IntPtr lparam) + 0x57 bytes
[Native to Managed Transition]
[Managed to Native Transition]
System.Windows.Forms.dll!System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(int dwComponentID, int reason = -1, int pvLoopData = 0) + 0x24e bytes
System.Windows.Forms.dll!System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(int reason = -1, System.Windows.Forms.ApplicationContext context = {System.Windows.Forms.ApplicationContext}) + 0x177 bytes
System.Windows.Forms.dll!System.Windows.Forms.Application.ThreadContext.RunMessageLoop(int reason, System.Windows.Forms.ApplicationContext context) + 0x61 bytes
System.Windows.Forms.dll!System.Windows.Forms.Application.Run(System.Windows.Forms.Form mainForm) + 0x31 bytes
|
|
|
|
|
srng.net wrote: Could you please guide me regarding any possible reason for the same?
The reason is quite simple, as noted in the exception message you have an uninitialised object reference. The cause, however, is far more difficult to determine. You need to look at the code to try and see what references are being made/used around the point of the exception. Perhaps add some debug code or link to your program with the debugger when the exception occurs.
Since you are using a third psrty tool you may also like to talk to the suppliers to see if it could be an issue with their code.
It's time for a new signature.
|
|
|
|
|
Hi Richard,
Thanks for the reply.
The reason is not the one which is seen at upper level.(Object not set to an instance of an object)
This is caused due to Application.ThreadContext.OnThreadException.
Here I am not able to get the reason for Application.ThreadContext.OnThreadException.
If you see the detailed log, there we can ,after NativeWindow.Callback this exception is raised inside System.Windows.Forms.dll.
Why the dll has raised an exception?
My point of view, This can not be becasue of third party tool. Reason : Again we can look into the StackTrace where the exception is raised by System.Windows.forms.dll and third party tool is just passing comand to WM_ExitSizeMove and leaving the handle to windows.
I need to know Why this exception is raised.
|
|
|
|
|
Since this appears to be somewhat random I can only repeat my previous suggestion that you add debug code or trap the application with he debugger when the exception occurs. Without understanding your code or the third party library it is impossible to make any other suggestions.
It's time for a new signature.
|
|
|
|
|
srng.net wrote: My point of view, This can not be becasue of third party tool. Reason : Again we can look into the StackTrace where the exception is raised by System.Windows.forms.dll and third party tool is just passing comand to WM_ExitSizeMove and leaving the handle to windows.
The problem can very well be inside the third party library, or how you're using it. If your updating controls from anything other than the UI thread, behavior is unpredictable. It should throw an exception about the cross-thread boundry call, but that's not guaranteed to be thrown in all cases.
I'd get with SyncFusion about this and explain what the circumstances are that threw the exception, how the control is being used, ...
|
|
|
|
|
Dear all,
This is my situation:
I try to create text file by using below code:
using (FileStream fs = File.Create(path)){};
It runs ok at debug mode, file is create at [path].
But nothing happens at release mode.
What wrong with this code? Pls. explain for me if you know.
|
|
|
|
|
you should put that in a try-catch and look at the Exception.ToString().
what is the exact content of path?
does the path exist? (if relative, it could be different in release vs debug)
Which Windows edition?
|
|
|
|
|
Thank for your reply.
About your question, I answer as below:
- I also put the try-catch & look for Exception, but there is no exception.
- The path is absolute path: C:\Program Files\MyFolder and it is existed.
- I run in Window XP, VisualStudio 2003.
|
|
|
|
|
If you are trying to write to Program Files it could be a permissions issue. I would try another path that is definately going to accessible such as:
Environment.GetFolderPath(Environment.SpecialFolder.MyDocuments)
To get the path you're using ath the moment I would do it this way:
string folderPath = Path.Combine(
Environment.GetFolderPath(Environment.SpecialFolder.ProgramFiles), "MyFolder");
I doubt that is related to your problem but may avoid problems in future.
|
|
|
|
|