I will take into account your 2 cents :). Still, the question is open.

Hi guys, I'm confused. I need to create interprocess communications between x64 and x86 processes running on the same machine. Can I use COM for it? Cannot see anything on web. Or does that mean that I must use DCOM? Thanks for help.

Hi, all. Does anyone know, if there is the way to catch when process being debugged call (directly or indirectly) any function from specified DLL? So the perfect thing for me, if VS could break when the execution enters the specified DLL address space. It would be perfect, if I could see the call stack (surely, I don't expect the function names for modules without debug info). Background: We are developing plugins for the complex application, that already contains a lot of code. I get weird behavior with CUDA. So want to check if some of the code is calling any of CUDA functions before me. Regards, Ivan

No I cant. Found a resolution. System::Windows::Threading::Dispatcher class does exactly what I need. And it doesnt require a UI control (like COntrol::BeginInvoke). Woeks perfect.

If this window will be in the same thread as main UI thread (which is requirement) - it will block application anyway.

Hi, Here is a situation. I need to perform long operation in UI thread. I must do it in UI thread, cause algorithm uses 3rdparty resources managed by UI thread. And these resources are not thread safe. So, I do it in UI thread. Because operation is very long I would like to not block the application. What I want is: 1) Interrupt algorithm execution. Store some message in message queue that algorithm must be resolved. 2) Application process all pending events in the queue (key eents, mouse events, draw events etc). 3) I get the the control again in some my handler. (All in the same thread) Similar to what I would do with PostMessage. Like a System::Windows::Forms::Timer with 0 interval (which is not allowed). How can I do that? And here is another detail: I'm doing all this NOT from UI control class. In fact I do it in static member function. But I'm in main(UI) thread. Thanks. /////////////////////////////////////////////////////////////////////////////// Found a resolution. System::Windows::Threading::Dispatcher class does exactly what I need. And it doesnt require a UI control (like COntrol::BeginInvoke). Works perfect. Theme closed.

modified on Wednesday, February 23, 2011 8:47 AM

Wow, I found a problem. Although this is my (no big) mistake, the result is just unexpected. virtual void set(const System::Drawing::Rectangle rect) {m_clientRectangle = rect;} Should be replaced with: virtual void set(System::Drawing::Rectangle rect) {m_clientRectangle = rect;} No const! Well I know const doesnt mean here anything. I've tried to use const reference from the very beginning. Then it failed to compile, I removed reference, but forgot to remove const. As a result - 5 hours wasted because of const that actualy doesnt mean anything! Fairy .NET :)

Hi all! I have big experience in the unmanaged C++. And have almost no experience in all these NET things. So, I started a project using managed C++ yesterday. Looks, like it will put me to the grave... For the context. I'm writing a plugin for ClearCanvas application. My plugin already have some classes that are inherited from the classes in the ClearCanvas SDK. Plugin is loading and working well. Now imagine the situation. I define a new class that inherits the simple interface. The inheritance model is: IDisposable->IRenderingSurface->MyClass IRenderingSurface is just a simple interface that declares 4 properties without implementation of them. So I implement my class like this:

ref class VolumeRenderingSurface :
public ClearCanvas::ImageViewer::Rendering::IRenderingSurface
{
public:
// Constructor.
VolumeRenderingSurface(System::IntPtr windowID, int width, int height);
// Destructor
~VolumeRenderingSurface();

        /// Window ID property
        property System::IntPtr WindowID
        {
            virtual System::IntPtr get() {return m\_windowID;}
            virtual void set(System::IntPtr id) {m\_windowID = id;}
        }
        /// Context ID property
        property System::IntPtr ContextID
        {
            virtual System::IntPtr get() {return m\_contextID;}
            virtual void set(System::IntPtr id) {m\_contextID = id;}
        }
        /// Client rectangle property property
        property System::Drawing::Rectangle ClientRectangle
        {
            virtual System::Drawing::Rectangle get() {return m\_clientRectangle;}
            virtual void set(const System::Drawing::Rectangle rect) {m\_clientRectangle = rect;}
        }
        /// Clip rectangle property property
        property System::Drawing::Rectangle ClipRectangle
        {
            virtual System::Drawing::Rectangle get() {return m\_clipRectangle;}
            virtual void set(const System::Drawing::Rectangle rect) {m\_clipRectangle = rect;}
        }
    private:
        System::IntPtr m\_windowID;
        System::IntPtr m\_contextID;
        System::Drawing::Rectangle m\_clientRectangle;
        System::Drawing::Rectangle m\_clipRectangle;
    };

The constructor and destructor are defined but empty. I even DONT use this class anywhere, just define it.

Yes, I tried. Well, actually I think this is file caching problem. Seems like caching is not always work well in my case. Will try to disable it and do some caching on my own.

Thanks Adrew, I will consider the situation with file caching. Need to investigate on this more. Meanwhile, are you think that rare disk accesses by other programs can reduce speed of my accesses in 5 times? I'm making sure that no heavy HDD operations are performed by other programs, but other programs for sure doing disk accesses even in the idle mode.

Thaddeus Jones wrote:

Maybe you could increase your input buffer then from 512 bytes to say 100Mb, and every time you've processed the 100Mb from memory, you'll read a new 100Mb. Similarly, writing your output to a memory buffer (say also 100Mb) and once your buffer is full writing that to file, should help with speed too.

I've tried this approach. Although it gives slight speed increase, it doesnt resolve the problem of chaotic speed.

The problem is not "Algorithm is slow", but "Algorithm speed is too chaotic". Sometimes it's done 5 times faster then usual, this means - it should always be done 5 times faster. I agree, that access speed can vary a little, but 5 times... I think this is something that should be puzzled out.

My files are always one the same drive in all tests. When it does in 1:54 or 24 seconds.

Thaddeus Jones wrote:

Note that some variation in disk speed can't be prevented in a multitasking OS where other programs might be using the disk too.

I always ensure no other work is running. Also I'm looking in the "Resource monitor", no big HDD accesses except my program.

Thaddeus Jones wrote:

If your memory permits, you could consider reading the entire input file to memory at once at the beginning of your algorithm and then processing it and writing the results.

No this is not possible, algorithm should work with unlimited file size.

Hi, Using C++, std::fstream, Windows. I have an algorithm that processes large file (actually this is the series of algorithms, but lets consider only one, cause others having the same problems). In general this algorithm reads chunks of data from one file and write to the other file with during some realignment (For reference, I'm doing realignment of the 3d volume data). I'm reading chunk size is 512 bytes, writing chunk size is 16 kb. Usually this algorithm finishes in 1 minute and 50 seconds. But I noticed that sometimes (rarely) it finishes in 24 seconds! Processing the same file, the same execution path. I've started to search for the reasons of why this slowdown is happening and how can I control that. 1) I have tried increasing the coalescing of the accesses to disk 2) I have considered the fragmentation problem (the file that I write is wrote in small chunks, therefore it's fragmented, about 600 fragments). When I resolved fragmentation problem (so, it's guaranteed that file is not fragmented) - I didnt got anything, still this chaotic access speed. 3) I have investigated the probability, that Windows flashes my memory buffers to HDD. No, that's not the case. 4) I have found that if I do all this operation on the other physical disk (not the one with OS) - I get this slow down more rarely, and algorithm usually finishes in 40 seconds (but anyway, speed is of HDD access is chaotic). Frequently during the same execution, access speed is rising or falling down, may be few times. This looks like my accesses are going out of tact with some internal HDD or OS operations, don't know. Anyone, have some experience or idea? Thanks.

Btw, here is from doc. Note SIGINT is not supported for any Win32 application. When a CTRL+C interrupt occurs, Win32 operating systems generate a new thread to specifically handle that interrupt. This can cause a single-thread application such as one in UNIX to become multithreaded, resulting in unexpected behavior. So terminating from Ctrl+C will not work. Try to kill process from task manager.

Did you tried this in debugger? I guess with debugging it will not work. Try to make infinite loop instead. I mean try following: In main() make infinite loop. In signal handler need to do something to identify we here, probably type to console (but this might not work). Run application without debugging. It's important, cause things like this might behave different when debugger attached. I didnt tried it myself yet, going to check this on monday.

Hey, I know how to execute some code when application closing in normal case. I'm not novice, and know how Windows messages system is working. The question is more advanced. What if for example, something go wrong, application freezing - and user terminates it using task manager, terminates it dirty? I need to do some code here. Probably this is impossible, but look at the answer Michael Godfroid gave me above. This seems to be what I look for. So I'm going to investigate this.

Well, the questions was not "How terminate process?", but "How to execute some code when process terminated normal or abnormal?" :).

This will work only in normal program termination. But if for example application is freezed and user wants to shut it with Task Manager - the execution will not run to main loop, cause application is freezed and dont getting messages from queue. Therefore I need some OS-level way to catch abnormal termination.

Yes, that's what I need, thanks!