problem when run the application using cntrl+F5. Wintech OPC DLL
-
Hi all, I have an MFC application for which I have integrated OPC function using Wintech OPC DLL. This application is an OPC Client which connects to a OPC Server and gets values from it using OPC communication. I call the OPC functions in my application. I used WPF(dll created by C#) in this application for some graphics and turned on the project setting "Common Language Runtime Support (/clr)" When I run my application in VS2008 using F5, it runs without any issues it shows correct values. But when I run the same application using Cntrl+F5 or directly run the EXE, it runs but it shows junk values. Notes Suppose i change project setting from "Common Language Runtime Support (/clr)" to "No Common Language Runtime support" it is not supported WPF dll. Please help ;) ;) ;) بلیط هواپیما ثبت دامنه طراحی سایت طراحی سایت فروشگاهی طراحی سایت شرکتی تبلیغات گوگل هاست لینوکس
-
Hi all, I have an MFC application for which I have integrated OPC function using Wintech OPC DLL. This application is an OPC Client which connects to a OPC Server and gets values from it using OPC communication. I call the OPC functions in my application. I used WPF(dll created by C#) in this application for some graphics and turned on the project setting "Common Language Runtime Support (/clr)" When I run my application in VS2008 using F5, it runs without any issues it shows correct values. But when I run the same application using Cntrl+F5 or directly run the EXE, it runs but it shows junk values. Notes Suppose i change project setting from "Common Language Runtime Support (/clr)" to "No Common Language Runtime support" it is not supported WPF dll. Please help ;) ;) ;) بلیط هواپیما ثبت دامنه طراحی سایت طراحی سایت فروشگاهی طراحی سایت شرکتی تبلیغات گوگل هاست لینوکس
You will need to provide much more information before anyone can help you with this. You say that it shows junk values; what are those values and why are they junk? What is the code that produces them, and what input data is used to create the values in the first place?
-
Hi all, I have an MFC application for which I have integrated OPC function using Wintech OPC DLL. This application is an OPC Client which connects to a OPC Server and gets values from it using OPC communication. I call the OPC functions in my application. I used WPF(dll created by C#) in this application for some graphics and turned on the project setting "Common Language Runtime Support (/clr)" When I run my application in VS2008 using F5, it runs without any issues it shows correct values. But when I run the same application using Cntrl+F5 or directly run the EXE, it runs but it shows junk values. Notes Suppose i change project setting from "Common Language Runtime Support (/clr)" to "No Common Language Runtime support" it is not supported WPF dll. Please help ;) ;) ;) بلیط هواپیما ثبت دامنه طراحی سایت طراحی سایت فروشگاهی طراحی سایت شرکتی تبلیغات گوگل هاست لینوکس
Most likely your code relies on a variable being zero or a BOOL false which you haven't specifically set to zero/false. Look at all your variables which require a preset zero value and make sure you set them. When you run in debug mode because it is going to display things it first zeros all variables, that does not happen when you run in normal mode. This for example will print 0 in debug F5 mode but could print anything in normal ctrl-F5 mode because i is not set
int i;
printf("i = %i\n", i);In vino veritas
-
You will need to provide much more information before anyone can help you with this. You say that it shows junk values; what are those values and why are they junk? What is the code that produces them, and what input data is used to create the values in the first place?
Richard Here is the statement
HANDLE hBmp = (HBITMAP) LoadImage(AfxGetInstanceHandle(), \_TEXT("C:\\\\DriveRichEdit\\\\DriveRichEdit\\\\DriveRichEdit\\\\res\\\\bullet\_red.png"), IMAGE\_BITMAP, 0, 0, LR\_LOADFROMFILE);As leon mentioned LoadImage may not work with .png files I am trying to emulate Visual Studio Debugger Breakpoint, when I used the RichEdit OLE interface and look at the SetSel parameters I see the first value (The x value as 1) however is stands away from right edge of the Parent Dialog frame (maybe by 1/8 of inch). Looking at the image in file explorer it looks just fine but when I am open the image in paintbrush I can see a rectangular white border around it and maybe that is part of the problem. If that is a problem would you have any suggestion for me how to get an image ie. red bullet, I picked this one up by doing a google search thanks
-
Most likely your code relies on a variable being zero or a BOOL false which you haven't specifically set to zero/false. Look at all your variables which require a preset zero value and make sure you set them. When you run in debug mode because it is going to display things it first zeros all variables, that does not happen when you run in normal mode. This for example will print 0 in debug F5 mode but could print anything in normal ctrl-F5 mode because i is not set
int i;
printf("i = %i\n", i);In vino veritas
Are you sure variables are not initialized for a debug build when run with ctrl-F5? ctrl-F5 only implies that the code will be run without attaching the VisualStudio debugger. It does not mean the code will be run in release mode - there may not even be a release mode executable to run. I do know that you can run a release build with F5, and when you inspect an uninitialized variable, it will most likely not show a null value, just as you described - but that does not depend on whether or not you attach a debugger.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
-
Are you sure variables are not initialized for a debug build when run with ctrl-F5? ctrl-F5 only implies that the code will be run without attaching the VisualStudio debugger. It does not mean the code will be run in release mode - there may not even be a release mode executable to run. I do know that you can run a release build with F5, and when you inspect an uninitialized variable, it will most likely not show a null value, just as you described - but that does not depend on whether or not you attach a debugger.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
You are getting build configuration mode as in "debug" and "release" mode come in that isn't relevant. The act of connecting a debugger does it's thing which is connect to the memory space, function and variables it doesn't give a rats about build mode. From a memory point the key thing it does is drop it's own heap manager which has been forever but started to be improved in VS2014 and now it connects to that whole memory display gadget that seems to get slower and slower each release. C++ Debugging Improvements in Visual Studio "14" | C++ Team Blog[^] That means whenever you run the debugger the heap is different to normal unless you go thru the hijinx to turn it off which used to be as simple as _NO_DEBUG_HEAP = 1 but like everything it has gotten successively harder.
In vino veritas