bingo! the DLL was set to /MT[d] - I changed that to /MD[d] and it seems to work (just gave it a quick shot) thx, man! :rose: :wq

hi, i'm writing a (legacy, non-MFC) dll and there might get an exception thrown in there. it is caught in the exe-file that uses that dll. dll: //some error throw new CSomeException(); exe: catch (CSomeException *e) { e->SomeFunction(); // works fine delete e; // crash } the delete-call crashes because the object is not a valid *local* heap-pointer. stepping in dbgheap.c reveales the following passage /* * If this ASSERT fails, a bad pointer has been passed in. It may be * totally bogus, or it may have been allocated from another heap. * The pointer MUST come from the 'local' heap. */ _ASSERTE(_CrtIsValidHeapPointer(pUserData)); // fails so, finally. how am i supposed to handle this? i mean throwing an exception in a library isn't that uncommon, is it? :confused: :wq

yup thx. i just figured out how to use Wide...()

CStringW str("äö€èéß");
long size = str.GetLength()*6+1;
char *out = new char[size];
if (!WideCharToMultiByte(CP_UTF8,0,str,-1,out,size,NULL,NULL))
{
DWORD err = GetLastError();
}
delete [] out;

*6 is a bit exaggerated, but you never know - memory is cheap nowadays ;) i'll use that multitowide-function too - thx for your reply. things look way smoother now ;) :wq

but MultiByteToWideChar() doesn't construct a UTF-8 encoded string, does it? afaik the point in UTF-8 is that characters < 0x7F are still only 8bit wide. btw: i'm on VS.NET 2003 if that makes any difference. :wq

hi all, i did never care that much about unicode, WCHAR, T_(), UTF-X and all these character-width things. but now someone wants to have an UTF-8-encoded string from my application. so now i'm sitting here for hours reading FAQs and postings and still haven't found the CString::ToUtf8(/*out*/ BYTE *pUtf8String, /*out*/ long &nSize) function. ;) where is it? for real: what's the easiest way to just get that CString i have into UTF-8? (my app is compiled without _UNICODE - so the chars in the CString are all 8 bit wide). tia :wq

roger that! i sent an email. thx for the hint. :) :wq

i was just reading the MSDN-Library on Events for Thread-Synchronization and stumbled across the following code:

#define NUMTHREADS 4
//...
HANDLE hReadEvents[NUMTHREADS] // ...
DWORD i // ...
for(i = 1; i <= NUMTHREADS; i++)
{
hReadEvents[i] = CreateEvent( // ...

i mean - does anyone check these examples? obviously this code accesses memory beyond the array-boundaries: hReadEvents[4] in the last loop. :wtf: see here: Using Event Objects it's in the first code example or am i missing something? :confused: :wq

i've done some basic socket programming so far and there's one thing i'm unable to explain. it works, but i don't know why. :wtf: i'm sitting behind a proxy-server here and when i write a program using sockets, i just use the usual socket-functions provided by the socket-api. my program works fine here behind the proxy and without any changes at other locations, where there is no proxy. why? other programs like browsers, winamp and the like have an extra proxy-settings dialog and in fact they're unable to connect to the internet, when i don't specify one there. can someone explain that to me, please... :rolleyes: :wq

ok. i cross-checked that thing with VS6 and the following turns out: the VS6-client crashes when using the VS.NET server the VS.NET-client crashes when using the VS.NET server the VS6-client works correctly with the VS6 server the VS.NET-client works correctly with the VS6 server so i believe there is a bug in the VS.NET automation-server MFC-implementation when using a VARIANT-parameter. and now? how can i report this. :confused: or maybe i made a mistake somewhere, but i don't know where... :~ :wq

it even doesn't work, when i compile the server as a dll. in that case, everything is running in the same process and i can debug each and every step. just before the server-function is called, there are some fancy stack-creation and inline-assembler thingies in the code. when the function is called then, there's crap on the stack! ah. just found one more: even the return address seems to be corrupt. when i return from the server-function into the mfc-wrapper-code i end up higher than i started! :omg: the result is: the server-function is entered again and afterwards that inline-assembler-code wants to derefence a NULL-pointer. bang! :laugh: maybe there's an error in the VC++.NET implementation of that code? or maybe i have some wrong settings in my project? weird! :~ :wq

are there any known issues with dispatching VARIANTs from one app to another in VS.NET? when dispatching BSTRs and the like, everything goes fine. i tried some older applications (compiled under VS6) on my computer and they do work properly (using VARIANT as a paramter through automation). i built the very easiest example of one server-app exporting one function VARIANT Test(VARIANT var); and one client using this function through automation. when debugging the client, the server gets properly loaded and the mfc-dispatchwrappers all do their job well (at the and of F11-ing the client the VARIANT-argument is ok as i constructed it). but when i debug the server, the VARIANT-argument getting in there is crap. moreover: it is different for each debugging-session. as the proper functions get called, i assume, there's everything ok with registring the component and that stuff. is there anything known about this issue? any hints and ideas are greatly appreciated... :| thx. :wq

hi, i have the well-known worker-thread doing some computations in the background. when there is an exception raised in this thread, it simply vanishes into hyperspace. X| is there any standard-way of handling exception thrown by the worker-thread in the calling thread? i could do numorous nasty hacks and workaround, but i don't know any "nice" way :-O thx for ideas. :wq

there's useful project on "the evil other site" ;) http://www.codeguru.com/system/Lock.shtml the secret is: you need to install a system-hook. the one capturing mouse-events needs to reside in a dll. i once did that with C++ but i have no idea whether this works with C#... :~ :wq

look at this little application using System; namespace ConsoleApplication2 { class Class1 { enum Test : byte { zero = 0x00, foo = 0x7F, middle = 0x80, max = 0xFF } [STAThread] static void Main(string[] args) { Test test; test = Test.zero; Console.WriteLine("{0}",test); test = Test.foo; Console.WriteLine("{0}",test); test = Test.middle; Console.WriteLine("{0}",test); test = Test.max; Console.WriteLine("{0}",test); } } } running that writes the correct values to the console, but if you debug the main-function step by step, you realize, that first the debugger shows the value of test as 'zero' and 'foo', but middle and max are shown as '-128' and '-1'. :wtf: seems to me, the debugger assumes, all enums are based on signed types (which byte is obviously not). was really confusing to me... :| :wq

i'm not sure, but isn't there a subtree of the base-classes in the classview? there you should find the original of your function and use the context-menu to add an override in your child-class. at least, thats the way in C#, don't know about C++. :wq

now i did a 'hack' that works for me. :)

public class TimedUdpClient : UdpClient
{
private int timeout = 1000; // 1 sec default
private Thread timeoutWatchdog;

/// /// Get/Set the receiving timeout in milliseconds (1000 = 1sec)
/// 
public int Timeout
{
	get { return timeout; }
	set { timeout = value; }
}

public new byte\[\] Receive(ref IPEndPoint remote)
{
	timeoutWatchdog = new Thread(new ThreadStart(StartWatchdog));
	timeoutWatchdog.Start();
	try
	{
		byte\[\] ret = base.Receive(ref remote);
		return ret;
	}
	catch (SocketException)
	{
		return null;
	}
}

private void StartWatchdog()
{
	Thread.Sleep(timeout);
	this.Send(new byte\[\] {0x00},1,"",8000);
}

}

my little test-program from two or three postings above didn't receive the packets since they have to be sent on the same socket (at least i believe that). when this byte from my watchdog is sent, there's an exception ("connection closed by remote" or something like that) raised somewhere inside UdpClient.Receive(). it would be nicer, if it would just receive the byte and one could distinguish by the sender, if that packet was sent by the watchdog (thus, on the same socket) or comes from outside. UDP is a connectionless protocol, so i'm not sure, how such a connection-closed-excpetion may occur, but actually it does :wtf: anyways. all i wanted, was stop Receive() from blocking and this way it works. :) thx to everyone that helped. (also the ones that read, thought and had no idea) :wq

at first, both SocketOptionLevel.Udp and SocketOptionLevel.Tcp raise an exception when being used with SocketOptionName.ReceiveTimeout. it seems you have to use SocketOptionLevel.Socket instead. but that even doesn't help. the Receive()-function still blocks. i don't know what that ReceiveTimeout is for :( :wq

hey, this looks cool. will try it tomorrow :) although i will try SocketOptionLevel.Udp instead of Tcp first ;) thx anyway. :) :wq

just a little bumpage ;), in case someone thinks: "hey this is just a 'question-answer-thx'-thread and i don't have to look at it" :rolleyes: if that gets fixed, i'm ready to post my first article here on codeproject. so could anyone please give me an idea? :rose: :wq

...you have to send a datagram to yourself for the thread to unblock... i've tried, but it doesn't seem to work. :( what's wrong with this little console-application? [STAThread] static void Main(string[] args) { Class1 foo = new Class1(); foo.MainLoop(); } public void MainLoop() { Thread listener = new Thread(new ThreadStart(Listen)); listener.Start(); UdpClient sender = new UdpClient(); IPEndPoint self = new IPEndPoint(IPAddress.Loopback,7789); sender.Send(new byte [] {0x01},1,self); while (listener.IsAlive) ; } void Listen() { UdpClient ear = new UdpClient(); IPEndPoint remote = new IPEndPoint(IPAddress.Any,0); ear.Receive(ref remote); Console.WriteLine("Got some Input from {0}",remote); } :wq