|
hi there,
i use TAPI to control modem,now i can dial or hang up but i dont know how to send data over a connected line,what should i do?
thanks
|
|
|
|
|
Hello,
I wrote a native C++ dll.
One of the functions it exports receives a string (LPCSTR to be exact), and keeps this string in order to use it later.
When my C# app simply sends a string to the dll, the GC is collecting it as soon as the function returns.
Problem is, I need that string in other functions.
So I've tried using GCHandle like so:
Global stuff:
string s = "MyVeryImportantString";
GCHandle gch; Inside a C# function:
gch = GCHandle.Alloc(s, GCHandleType.Pinned);
nativeDllFunction(GCHandle.ToIntPtr(gch)); Later on I free the GCHandle of course.
That didn't work, but that's probably because I'm doing something wrong, and it probably has a solution...
That's not why I'm writing right now...
I'm here to ask your opinions about my workaround...
Inside my native dll, I wrote a function to allocate new memory for the string, using malloc .
This way I'm not holding a pointer to the string the GC is collecting, but a pointer to a copy I made.
Doing so could help future mistakes with managed assemblies which use this dll.
Moreover, it saves me the need to worry, and the time to write a proper GCHandle code.
As I'm new to dll programming in C++, I don't really know fashionable methods of doing stuff. Is it bad to use the malloc function inside of my dll?
Is it better to use the GCHandle method instead?
Thanks in advance,
Shy.
|
|
|
|
|
Hi,
in order to prevent the gc from deleting or moving an object, you need a GCHandle AND pinning,
as in the following code snippet:
Stream stream=type.Assembly.GetManifestResourceStream(resourceName);
int len=(int)stream.Length;
byte[] buf=new byte[len];
stream.Read(buf, 0, len);
GCHandle handle=GCHandle.Alloc(buf);
IntPtr ptr=Marshal.UnsafeAddrOfPinnedArrayElement(buf, 0);
int res=sndPlaySound(ptr, 4);
handle.Free();
You can postpone the last line (until the unmanaged code no longer uses the pointer),
but you should execute it eventually, otherwise the memory situation will deteriorate.
Luc Pattyn
|
|
|
|
|
How can I implement "OLE object" with C# and SQL
I need a simi way to do link to files with ADO.NET with SQL SERVER
like MS-ACCESS OLE Object to Insert and Edit >object like any file such as MS-Word, MS-Excel ..etc;
so When an User open GUI Application he would be able to (brows - save - Edit) the files on SQL Directly,,
thank you
my email:devloperx@yahoo.com
|
|
|
|
|
|
i want to pick up the workgroup name of the local host in c#. i want a solution instead of WMI, window services and web services.
I will be thankfull.
Muhammad Kashif
|
|
|
|
|
kashif,
you may consider using external function NetWkstaGetInfo from "netapi32" lib.
regards
|
|
|
|
|
Hello everyone,
The VS's Object Browser shows that Object is the base class for String.
Does this necessarily means that String is a reference type?
Thanks in advance,
Shy.
|
|
|
|
|
string is a special case. Strings are immutable, so that means that they can't be changed. s = s + ","; creates a new string, in a new location in memory. That's one good reason to use stringbuilder to do a lot of string concatenation.
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
|
|
|
|
|
Yes... I'm aware of that...
But what's the meaning of this?
Is String a reference or a value type?
|
|
|
|
|
It is a reference type, but that information was pretty trivial to discover ( I googled it, just to make sure ).
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
|
|
|
|
|
|
No. Even System.ValueType inherits from object. The fact that String doesn't inherit fom System.ValueType doesn't mean anyhting either. String s are treated specially - they are immutable.
Robert
|
|
|
|
|
And what about immutables? Are they value or reference types?
Or is it wrong to say that?
Are they not considered as reference nor value type?
|
|
|
|
|
No value type is immutable AFAIK, but most reference types are not, either. So there is no way to answer your question, it assumes a classification that does not exist.
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
|
|
|
|
|
Christian Graus wrote: No value type is immutable AFAIK
Actually, most value types are immutable. You never change their value, you replace it with a new value.
There are some exceptions, like the Point structure, that allows you to change it's properties separately.
---
b { font-weight: normal; }
|
|
|
|
|
Guffa wrote: Actually, most value types are immutable. You never change their value, you replace it with a new value.
There are some exceptions, like the Point structure, that allows you to change it's properties separately.
When you write code to replace a string "value", since the string "value" is immutable you are actually replacing the current string "object" with a new string "object". The old string "object" is eventually desposed of. However, a value type can be changed without replacing its address space with a new value type address space.
So, IMHO, Christian Graus is correct about no value type is immutable.
"We make a living by what we get, we make a life by what we give." --Winston Churchill
|
|
|
|
|
George L. Jackson wrote: When you write code to replace a string "value", since the string "value" is immutable you are actually replacing the current string "object" with a new string "object". The old string "object" is eventually desposed of. However, a value type can be changed without replacing its address space with a new value type address space.
If you consider any changeable value to be mutable, then a string variable is mutable, while the string data that it references is not. In fact that makes all reference types mutable, as you can change the reference.
Also, if all value types are mutable, then there is nothing special with the Point structure, that actually is mutable. The entire debate about mutable structures becomes a moot point if all structures should be considered to be mutable.
I would rather like to make the distinction based on whether the class or structure exposes any methods to change the state of it.
---
It's amazing to see how much work some people will go through just to avoid a little bit of work.
|
|
|
|
|
I understand your "immutable" point of view! I believe mine is mutating towards yours.
George
"We make a living by what we get, we make a life by what we give." --Winston Churchill
|
|
|
|
|
shyagam wrote: And what about immutables? Are they value or reference types?
Both value types and reference types can be immutable.
Being immutable only means that the type does not expose any methods to alter it's value.
---
b { font-weight: normal; }
|
|
|
|
|
Whats so ever,
strings are allocated on the heap as an array of chars, and are garbage collected, so definitely they are reference types. 100%!!
99% 100% 101%
|
|
|
|
|
For immutable objects, there is no difference in behavior between reference types and value types.
If you can't change it, it doesn't matter if changing it would change all references to that instance (reference type) or just the copy you got (value type).
But yes, internally string is a reference type; so passing a string around doesn't create lots of copies.
|
|
|
|
|
can anyone tell me why the heck am i getting this error here:
SomeTableAdapter.Update(SomeDataSet);
Error: System.Data.OracleClient.OracleException was unhandled
please help
All generalizations are wrong, including this one!
(\ /)
(O.o)
(><)
|
|
|
|
|
To handle exceptions, you need to surround your code with a try block, hand the exception in a catch block, and release resources in a finally block. Are you using try/catch/finally?
"We make a living by what we get, we make a life by what we give." --Winston Churchill
|
|
|
|
|
Of course i do!! im just heading to the point where i get the trouble so i dont post long messages in the forum.
All generalizations are wrong, including this one!
(\ /)
(O.o)
(><)
|
|
|
|