CodeGuru Home VC++ / MFC / C++ .NET / C# Visual Basic VB Forums Developer.com
Results 1 to 5 of 5
  1. #1
    Join Date
    Jun 2004
    Location
    New Jersey, USA
    Posts
    341

    Run App. Through VS vs. Exe file

    What is conceptual difference in running Application in release mode through VS or just by clicking executable from outside VS?
    The are must be a difference because I have console application that I run through VS and it is fine and if I run it by clicking exe file it never end I process runs forever even through it acts differently through VS. It was clearly a bug and I found it in a code but why it acted differently when running in VS and exe file, I though it is the same thing?

    By the way guys how you would recommend debugging console application that remains to run even if all code executed. Clearly, setting breakpoints and line by line execution will not help since it completes all lines of code. It must be some thread that never ends. I tried to use Spy++ that comes with .NET and VS but it was not clear at all, had so many different thread running. Is there any easier way to do this type of examination?

    Thanks a lot
    "We act as though comfort and luxury were the chief requirements of
    life, when all that we need to make us happy is something to be
    enthusiastic about."

    - Einstein

  2. #2
    Join Date
    Jan 2002
    Location
    Scaro, UK
    Posts
    5,940

    Re: Run App. Through VS vs. Exe file

    I really ought to write a book entitled "Fun with threads - the easiest route to an early grave."

    You really are hitting the main problem with threads - i.e. replication of problems is very, very difficult. Because of the way that all sorts of things work differently in debug builds (e.g. the GC works differently) some threading problems inherently show themselves up only in release builds. And only on certain machines too...

    The only thing I can suggest is to implement some sort of logging mechanism so you can track what's going on in each thread whilst your app is running. Only then can you track down (I use binary search mechanisms) where the problem arises, and hence how to fix it.

    There's no holy grail to this : just a lot of bog standard, brute force hacking away at the problem to discover what's wrong.

    Darwen.
    www.pinvoker.com - PInvoker - the .NET PInvoke Interface Exporter for C++ Dlls.

  3. #3
    Join Date
    Jun 2004
    Location
    New Jersey, USA
    Posts
    341

    Re: Run App. Through VS vs. Exe file

    Hey Darwen,

    I am always looking forward to your valuable answers. Thanks man, you have helped me in many occasions.
    I agree with you about thread, i think it is one of most complicated concepts in programming. Would you happened to know why it would act differently if you run it from VS in Release mode and from executable file.? Does it do the same thing? I know it is different in debug mode but in release conceptually it should be the same or I am missing something.

    BY the way I wanted to ask one more thing please. Remember, you provided me once with sample code for progress bar that you run on non-UI thread. It works great. I added many things to it and implemented it on the form with a lot of other features and controls. The only problem I have now is Refreshing when some task between when bar in incremented is taking long time. I set the form to refresh on every bar.PerfomrStep call, however for example when there is substantial time between consecutive PerformStep calls and window either minimized or other window is opened on top of it , the bar form will not refresh(images on it do not get refreshed) until next step is perfumed. I was wondering if there is anyway to refresh it. I am just not sure what event to use. The only thing that comes to my mind is to just refresh it using timer on constant bases but I do not think it is such a good idea. What do you think?

    Thanks a lot
    "We act as though comfort and luxury were the chief requirements of
    life, when all that we need to make us happy is something to be
    enthusiastic about."

    - Einstein

  4. #4
    Join Date
    Jan 2002
    Location
    Scaro, UK
    Posts
    5,940

    Re: Run App. Through VS vs. Exe file

    I'm not aware of any differences to doing Ctrl+F5 and double-clicking on the exe in a release build. There will be differences in how Windows manages the threads though : since you've got the IDE running in one case which eats up lots of memory.

    About your refresh problem - that sounds a little odd : the whole point of having the form on a seperate thread being shown by ShowDialog() is that it has its own message loop, and therefore should refresh itself automatically. Mine always do.

    At any rate, using a timer like this is no bad thing : just be sure to use a System.Threading.Timer and not a System.Windows.Forms.Timer. You want the dialog to refresh itself asynchronously.

    And remember to call Refresh() using Invoke i.e.

    Code:
    MyForm myForm;
    myForm.Invoke(new MethodInvoker(myForm.Refresh));
    The threading timer operates - yes you guessed it - in yet another thread, so .NET needs to marshal the call.

    Darwen.
    Last edited by darwen; October 11th, 2005 at 11:55 PM.
    www.pinvoker.com - PInvoker - the .NET PInvoke Interface Exporter for C++ Dlls.

  5. #5
    Join Date
    Jun 2004
    Location
    New Jersey, USA
    Posts
    341

    Re: Run App. Through VS vs. Exe file

    Thanks again darwen,

    Intersting thing with refresh that it work for everyhting but the images. I have lables and other constrols that get refreshed byitself. The only control that does not refresh automaitcly is ImgeBox. May be I am missing something specefic related thi this control
    "We act as though comfort and luxury were the chief requirements of
    life, when all that we need to make us happy is something to be
    enthusiastic about."

    - Einstein

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  





Click Here to Expand Forum to Full Width

Featured