C / C++ / MFC

problem when run the application using cntrl+F5. Wintech OPC DLL

15-Dec-19 22:36

I expect your code is wrong. But since you have not shown us what code you are using it is impossible to say more.

Member 1467670615-Dec-19 1:52

Member 14676706

15-Dec-19 1:52

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

بلیط هواپیما ثبت دامنه طراحی سایت طراحی سایت فروشگاهی طراحی سایت شرکتی تبلیغات گوگل هاست لینوکس

modified 26-Dec-19 9:23am.

Re: problem when run the application using cntrl+F5. Wintech OPC DLL

Richard MacCutchan15-Dec-19 3:54

Re: problem when run the application using cntrl+F5. Wintech OPC DLL

15-Dec-19 3:54

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?

ForNow16-Dec-19 2:03

ForNow

16-Dec-19 2:03

Richard

Here is the statement

C++

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

Re: problem when run the application using cntrl+F5. Wintech OPC DLL

leon de boer15-Dec-19 21:39

Re: problem when run the application using cntrl+F5. Wintech OPC DLL

15-Dec-19 21:39

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

Stefan_Lang16-Dec-19 5:35

Stefan_Lang

16-Dec-19 5:35

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)

Re: problem when run the application using cntrl+F5. Wintech OPC DLL

leon de boer17-Dec-19 3:45

DIrectX9 error shows up only in debugger

17-Dec-19 3:45

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

Member 953078713-Dec-19 6:50

Member 9530787

13-Dec-19 6:50

I'm working on a C++ native code graphics application using DirectX9. I use the latest version of Visual Studio Community 2019. When working in the IDE the application crashes from time to time with a message like
"Exception thrown at 0x00007FF9762975D6 (nvd3dumx.dll) in NNetSimu.exe: 0xC0000005: Access violation reading location 0x000001B388FE1A3E."
So far I could not reproduce the error, it happens once in while. The strange thing is: If I call the application directly, it runs very stable, the problem occurs only in the IDE.
The crash happens always during the end of a frame, typically during swapChain->Present. My code:

void D3D_driver::EndFrame( HWND const hwnd )
{
    HRESULT hres;
    hres = m_d3d_device->EndScene();                                       assert(hres == D3D_OK);
    hres = m_d3d_swapChain->Present( nullptr, nullptr, hwnd, nullptr, 0 ); assert(hres == D3D_OK);
    m_id3dx_font->Release();      
}

I could live with the situation, the app runs smoothly without IDE, but it is annoying during development.
Any ideas how I could further investigate the problem?

modified 13-Dec-19 19:32pm.

Re: DIrectX9 error shows up only in debugger

Richard MacCutchan14-Dec-19 0:42

Re: Can Bullet numbering in

14-Dec-19 0:42

Since the problem appears to be within Microsoft's library it would be best to report it to them.

Can Bullet numbering in

ForNow9-Dec-19 2:27

ForNow

9-Dec-19 2:27

Hi

Can bullet used as numbering in paraformat/ CricheditCtrl::SetPartaFormat be colored

I am trying to create an image such as the breakpoint bullet in Visual Studio debugger

thanks

Richard MacCutchan9-Dec-19 4:37

Re: Can Bullet numbering in

9-Dec-19 4:37

Does the SetParaFormat method contain an option to set the colour, or does it use the default of the current font?

ForNow9-Dec-19 4:55

ForNow

9-Dec-19 4:55

Thanks wasn't sure if bullets could be colored I'll use the the SetSelectionCharFormat member crTextColor of charformat to color the text

thanks

V2008: All my breakpoints disable. Mouseover shows "The breakpoint will not currently be hit. No executable code is associated with this line."

charlieg8-Dec-19 10:42

Re: V2008: All my breakpoints disable. Mouseover shows "The breakpoint will not currently be hit. No executable code is associated with this line."

8-Dec-19 10:42

Ripping my hair out with this one. I develop for some Windows Embedded Compact 7 products where we use VS2008 with add-on SDKs. All service packs applied, I've been using the same setup for the A week or so ago, I did a code merge between two branches and broke on of my applications. In trying to debug the issue, I discovered that no matter where I placed breakpoints, they would immediately go clear with a warning. Mousing over shows the message in the title bar. In doing my debug of the debugger work, I have:

- full clean rebuild;
- delete all PDB, suo and ncb files;
- create a new application;

Nothing corrects the issue. In fact, the last item is a simple dummy hello world dialog app, and it has the same breakpoint issue. So something bad has happened to the installation I'm guessing. In reading all the SO discussions, it appears that most people solve this by making random changes until it starts working.

Does anyone have a definitive explanation or solution for this behavior?

Thanks

Charlie Gilley
<italic>Stuck in a dysfunctional matrix from which I must escape...

"Where liberty dwells, there is my country." B. Franklin, 1783
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759

charlieg8-Dec-19 10:48

Re: V2008: All my breakpoints disable. Mouseover shows "The breakpoint will not currently be hit. No executable code is associated with this line."

8-Dec-19 10:48

Seems I fixed this by doing a repair installation on VS2008. Should have thought of that last week.

leon de boer8-Dec-19 14:10

Re: V2008: All my breakpoints disable. Mouseover shows "The breakpoint will not currently be hit. No executable code is associated with this line."

8-Dec-19 14:10

The bigger question is why you are still using VS2008 given all the upgrades above you are free Smile | :)

WIN CE was supported until at least VS2015 from memory.

Update: Ignore that you are trying to debug you have to be on VS2008 my bad

In vino veritas

modified 8-Dec-19 19:27pm.

Stefan_Lang9-Dec-19 0:20

Stefan_Lang

9-Dec-19 0:20

In principle, you can choose a toolset from an earlier VS installation in any version of VS. If VS 2008 and a newer version are installed, you should be able to select the VS 2008 toolset in the newer VS for the purpose of debugging, or even building executables. Maybe intellisense won't like it, but you can disable intellisense if it gets too annoying.

Re: V2008: All my breakpoints disable. Mouseover shows "The breakpoint will not currently be hit. No executable code is associated with this line."

leon de boer9-Dec-19 1:52

Re: V2008: All my breakpoints disable. Mouseover shows "The breakpoint will not currently be hit. No executable code is associated with this line."

9-Dec-19 1:52

Pretty sure you have to have a stub running in Win CE target to debug and if I remember correctly it is tied to the VS version. You can definitely compile without issue but I recall issues with debugging.

In vino veritas

Stefan_Lang9-Dec-19 2:59

Stefan_Lang

9-Dec-19 2:59

Good point. I've never tried this with different target platform applications.

Re: V2008: All my breakpoints disable. Mouseover shows "The breakpoint will not currently be hit. No executable code is associated with this line."

charlieg9-Dec-19 3:05

Re: V2008: All my breakpoints disable. Mouseover shows "The breakpoint will not currently be hit. No executable code is associated with this line."

9-Dec-19 3:05

Good question, but it's the nature of embedded systems. My customers are still using systems they purchased in 2006. We're still supporting CE 5.0 and WEC7. Microsoft sort of lost their way after WEC7, and the tools stopped supporting the embedded arena. Microsoft was ripped a new bloody one with this decision, and eventually added support back into the Visual Studio, but the support does not extend back to 5.0 and 7.0. My team dug into this pretty deeply a few years back when we had to deal with this. Do you have knowledge of this changing?

charlieg9-Dec-19 3:09

Re: V2008: All my breakpoints disable. Mouseover shows "The breakpoint will not currently be hit. No executable code is associated with this line."

9-Dec-19 3:09

Well, I spoke to soon Sigh | :sigh:

. The re-installation did not fix this completely. My breakpoints are back, but any attempts at compiling is a disaster.

There was an issue from long ago (I even have notes back from 2017 on this) about issues with the default include order. My notes cover about 95% of what needs to be done to correct it, but I think I missed one important key. Sigh.

I'm backing up to a scrubbed system and re-installing everything. VMs are nice.

charlieg8-Jan-20 12:37

Allocating memory for struct pointer - error: invalid conversion from ‘void*’

8-Jan-20 12:37

I'm going to close this out for posterity's sake.

Part of the problem with having to use VS2008 is that people who make extensions don't test against very old versions, and let's face it, 2008 is a gnarly old thing (but it's better than EVC++). Anyway, a long about December of last year I was trying to track down an issue with stack allocation. One tool I tried to use is Intel's VTune. Once installed, my woes began. I scrubbed everything to recover. Not only did it hose the breakpoints, but things would not compile, etc. I'm a busy guy, and I hate not being able to go back and do a true cause analysis.

New post coming up Smile | :)

Vaclav_6-Dec-19 6:56

Vaclav_

6-Dec-19 6:56

I could use some very basic assistance solving this problem.
The struct is located inside class function and I am not sure if that is OK.
I am trying to port C code to C++.

Here is the error
I get same error for both test calls to malloc

../src/MODULES/M_BLUEZ/CBLUEZ.cpp:505:14: error: invalid conversion from ‘void*’ to ‘hci_dev_list_req*’ [-fpermissive]
   dl = malloc(HCI_MAX_DEV * sizeof(*dr) + sizeof(*dl));

Here is the offending code snippet

C++

<pre>	struct hci_dev_list_req *dl;
	struct hci_dev_req *dr;
	int dev_id = -1;
	int i, sk, err = 0;


	dl = malloc(HCI_MAX_DEV * sizeof(*dr) + sizeof(*dl));
	if (!dl) {
		err = errno;
		goto done;
	}

	dl = malloc(HCI_MAX_DEV * sizeof(struct hci_dev_req) + sizeof(uint16_t));

Thanks
Cheers

Re: Allocating memory for struct pointer - error: invalid conversion from ‘void*’

Richard MacCutchan6-Dec-19 7:12