VSS automation problem
-
I'm using VSS interface in my program. I'm getting the latest version of the file by using Get function in IVSSItemPtr. IVSSItemPtr vssi; COleVariant varBuf(strProjectFolder); vssi = m_vssdb->GetVSSItem( varBuf.bstrVal,0); vssi->Get( NULL,VSSFLAG_USERRONO | VSSFLAG_RECURSYES | VSSFLAG_FORCEDIRYES | VSSFLAG_GETYES ); The above code works perfectly for me. It gets the latest version. But I'm suffering from biggest disadvantage. Once this function is called it disables my main application. No messages are handled by main window, when the Get function is called. Once that function execution is finished then only Window accepts messages. Till then all the messages are blocked. Even all the threads are suspended. For large folders when we use Get function, it's takes very long time and it's quite annoying that Window gets disabled and all background threads are suspended. Is there any way to overcome it? I wanted to monitor the status of the Get function. Is there any way to run background thread to monitor it? Can we enable the Window to accept messages. Thanks, Stanly
-
I'm using VSS interface in my program. I'm getting the latest version of the file by using Get function in IVSSItemPtr. IVSSItemPtr vssi; COleVariant varBuf(strProjectFolder); vssi = m_vssdb->GetVSSItem( varBuf.bstrVal,0); vssi->Get( NULL,VSSFLAG_USERRONO | VSSFLAG_RECURSYES | VSSFLAG_FORCEDIRYES | VSSFLAG_GETYES ); The above code works perfectly for me. It gets the latest version. But I'm suffering from biggest disadvantage. Once this function is called it disables my main application. No messages are handled by main window, when the Get function is called. Once that function execution is finished then only Window accepts messages. Till then all the messages are blocked. Even all the threads are suspended. For large folders when we use Get function, it's takes very long time and it's quite annoying that Window gets disabled and all background threads are suspended. Is there any way to overcome it? I wanted to monitor the status of the Get function. Is there any way to run background thread to monitor it? Can we enable the Window to accept messages. Thanks, Stanly
Why not do it the other way around, and spin off a new thread to perform the get? Of course, you'll need to coinit your new thread and marshall your interface into the new thread, but that isn't exactly rocket science. Your 'get' thread can post a message when it's complete. Unfortunately, there don't appear to be any useful events that fire during the get, so you can't "monitor" as such. An alternative would be to handle the recursion yourself in the thread, and have the thread post messages to your UI thread or a window. The application 'hangs' for a simple reason; the UI thread it isn't pumping messages, because the call hasn't completed yet. When you say the threads are suspended, I'm guessing that none of them have their own message loops. Steve S Developer for hire
-
Why not do it the other way around, and spin off a new thread to perform the get? Of course, you'll need to coinit your new thread and marshall your interface into the new thread, but that isn't exactly rocket science. Your 'get' thread can post a message when it's complete. Unfortunately, there don't appear to be any useful events that fire during the get, so you can't "monitor" as such. An alternative would be to handle the recursion yourself in the thread, and have the thread post messages to your UI thread or a window. The application 'hangs' for a simple reason; the UI thread it isn't pumping messages, because the call hasn't completed yet. When you say the threads are suspended, I'm guessing that none of them have their own message loops. Steve S Developer for hire
Thanks a lot for responding. I tried using thread to perform 'get'. In this case also, once the 'get' function is called application is not responding to any messages even the message loop of each thread. The 'get' completely blocks other messages. I tried using recursion mechanism to 'get' file. There is a major drawback for this method. The performance is affected to a large extent. It's take very long time to get a big folder because it has to recurse to each folders and subfolders. Thats why I thought of shifting to single call mechanism to 'get' whole folder. Can you please help me with this problem? Thanks, Stanly
-
Thanks a lot for responding. I tried using thread to perform 'get'. In this case also, once the 'get' function is called application is not responding to any messages even the message loop of each thread. The 'get' completely blocks other messages. I tried using recursion mechanism to 'get' file. There is a major drawback for this method. The performance is affected to a large extent. It's take very long time to get a big folder because it has to recurse to each folders and subfolders. Thats why I thought of shifting to single call mechanism to 'get' whole folder. Can you please help me with this problem? Thanks, Stanly
:sigh: It is a lot of work (in terms of CPU time) to get a large folder and any subfolders. If you do it using the SourceSafe UI, time it and see how long it takes - and then compare that with your single get, and if possible, your recursive version. Doing the automation work can be a bit of a pain, but if your code is reasonable, it shouldn't be that much worse than using the SS UI. What exactly are your other threads doing, and have you adjusted the priority of them? It sounds like you're just CPU starved, and while SS uses a lot, you should be able to do other things at the same time - I have a snapshot utility that replicates a given SS db to a new SS db (eliminating any history) and I can run other stuff along side it, although I have a P4 2.8GHz cpu ... Steve S Developer for hire
-
:sigh: It is a lot of work (in terms of CPU time) to get a large folder and any subfolders. If you do it using the SourceSafe UI, time it and see how long it takes - and then compare that with your single get, and if possible, your recursive version. Doing the automation work can be a bit of a pain, but if your code is reasonable, it shouldn't be that much worse than using the SS UI. What exactly are your other threads doing, and have you adjusted the priority of them? It sounds like you're just CPU starved, and while SS uses a lot, you should be able to do other things at the same time - I have a snapshot utility that replicates a given SS db to a new SS db (eliminating any history) and I can run other stuff along side it, although I have a P4 2.8GHz cpu ... Steve S Developer for hire
I found that the CPU is much lesser(30%) than total CPU available. The single get is much faster than recursive version and also it's faster than SS UI. It's better than SS UI. The VSS database is located in remote machine. Is it because of reading from remote machine makes the application to freeze? One thread is to monitor the content of one folder. The control is never reaching this thread, once the 'get' function is called. I tried using timers also, timer event is also not happening. Thanks a lot for your help. Thanks, Stanly
-
I found that the CPU is much lesser(30%) than total CPU available. The single get is much faster than recursive version and also it's faster than SS UI. It's better than SS UI. The VSS database is located in remote machine. Is it because of reading from remote machine makes the application to freeze? One thread is to monitor the content of one folder. The control is never reaching this thread, once the 'get' function is called. I tried using timers also, timer event is also not happening. Thanks a lot for your help. Thanks, Stanly
stanlymt wrote:
One thread is to monitor the content of one folder. The control is never reaching this thread, once the 'get' function is called. I tried using timers also, timer event is also not happening.
How do you know that the thread is not running? Does it have it's own windows and message loop, or are you outputting to a debug window (TRACE/ATLTRACE/OutputDebugWindow)? The single get will be faster, but then you have to do your own monitoring of progress, which means looking for file change notifications etc. I suggested the recursive version because you said you wanted to have progress notifications, and this would be one way. I'm guessing that the SS UI does it this way, since there aren't events that get fired (at least, not that we get told about!). It might be the STA that's contributing to the lockups. You could try using CoInitializeEx to get an MTA instead (in both the main thread and the get thread), and see if that helps at all. When you say timers, do you mean SetTimer(), which will only cause WM_TIMER to be pulled out of the queue, which, as you're not pumping msgs, won't be happening.... Steve S Developer for hire
-
stanlymt wrote:
One thread is to monitor the content of one folder. The control is never reaching this thread, once the 'get' function is called. I tried using timers also, timer event is also not happening.
How do you know that the thread is not running? Does it have it's own windows and message loop, or are you outputting to a debug window (TRACE/ATLTRACE/OutputDebugWindow)? The single get will be faster, but then you have to do your own monitoring of progress, which means looking for file change notifications etc. I suggested the recursive version because you said you wanted to have progress notifications, and this would be one way. I'm guessing that the SS UI does it this way, since there aren't events that get fired (at least, not that we get told about!). It might be the STA that's contributing to the lockups. You could try using CoInitializeEx to get an MTA instead (in both the main thread and the get thread), and see if that helps at all. When you say timers, do you mean SetTimer(), which will only cause WM_TIMER to be pulled out of the queue, which, as you're not pumping msgs, won't be happening.... Steve S Developer for hire