|
mystorage[I}->len has the right value, I didn't check mystorage[I]->buffers for non NULL
but it has an address and the right data after the memcpy
However as Victor pointed out sockbuffer is from a different thread
I knew something was wrong when my rich edit didn't get populated running under the
debugger subtle storage overlays don't cause exceptions
I have a question if invoke exception handlers ( and I have to read up on it)
will it catch the exceptions that the VS debugger bypasses
Thanks
thanks
|
|
|
|
|
Ah We are getting Somewhere!
At least some code.
On the Off Chance of asking a stupid question, I do not see any declarations for the Index 'I', nor for the class 'mystorage', nor for the object 'as_id'.
Are you working on a PC or an IBM Main Frame, with z/OS Operating System.
I am getting Confused! 
Bram van Kampen
|
|
|
|
|
Well,
You have another post about the failures of optimizers. Do those threads relate to the same problem? (or even the same problem?)
I understand that you are in a state of desperation. Believe me, I've been there myself, many times and more. When all other options fail, you are left with nothing else left to blame, but the compiler. I must say, I use a Windows NT version of the Development Environment hailing back to 1998, and, that has indeed a few issues, which I have now documented and hence avoid.
For Instance, Standard Code like:
for(int i=0;i<A;i++){Foo(i);}
worked in Debug, but caused an exception in Retail.
The Work around was simple:
int i; for(i=0;i<A;i++){ Foo(i);}
Be Realistic, anything drastically wrong with the MFC Compiler or MFC Libraries, would very soon have thrown up issues world wide.
I understand that your code runs flawless in the Debug version, but bails out in the retail version. The difference between the two builds are far bigger than the application of an optimisation process. For starters they link into different MFC Libraries.
Have you tried: Why Program works in debug but not release mode By Microsoft, or, Surviving the Release Version in our own Code Project Site.
There is something trivial wrong with your code, that your compiler can read and interpret without generating a syntax error, but which also does something quite different than what you intended it to do, and causes an exception to be thrown in release mode. The Debug mode tends to be more tolerant of (wittingly or unwittingly) doing 'Smart' things.
In order to allow us to help you, show us some (or Much) of the offending Code by attachment.
Regards,
Bram van Kampen
modified 30-Jun-17 18:58pm.
|
|
|
|
|
I have a program that works just fine in all versions of 32 and 64-bit windows except for 10. I have tracked down the cause of the problem to UDP sockets. I have not been able to make them work with W10. TCP sockets work fine but UDP sockets are giving me fits. This same code works without issue on my old W7 box so I am now working on it just so I can make progress.
Does anyone know of a fundamental issue with W10 and UDP sockets or is it just some setting somewhere they I need to correct?
modified 28-Jun-17 13:48pm.
|
|
|
|
|
Rick York wrote: This same code works without issue on my old W7 box so I am no working it just so I can make progress.
Which same code?
Secondly, Windows 10 supports UDP as well as TCP, the thing to note here would be, are you implementing UDP protocol properly? UDP is a very notorious protocol, as there are several handy things, that are missing in UDP — which TCP can brag about. I would personally believe, that you would need to double check the usage or implementation of UDP clients.
Since you have not shared anything (code, working sample, UDP helpers etc.), it is hard to consider what might be doing wrong.
Before you start, understand that since most of the times UDP packets are used for malicious purposes, Windows may prevent them from entering, so please read the following resources before you starting doing anything,
UDP Communication is blocked by the Windows Firewall rule in WSFC
c# - Problems with UDP in windows 10. UWP - Stack Overflow
windows 10 Version 1607 dropped udp packets with activated multicast
The sh*t I complain about
It's like there ain't a cloud in the sky and it's raining out - Eminem
~! Firewall !~
|
|
|
|
|
Thank you for the links. They gave me a couple of hints to look into. Interesting coincidence : these apps communicate with cameras also but they aren't GigE and this is not a multicast problem, it's all unicast. I did not include code because the same code on both ends (camera and PC) works fine in XP and W7 and fails only on W10. Wireshark shows a well-formed packet being sent to the right destination but there is no response. It seems like it may be a firewall issue. That's where I am going to look next.
|
|
|
|
|
Afzaal Ahmad Zeeshan wrote: Before you start, understand that since most of the times UDP packets are used for malicious purposes, Windows may prevent them from entering, so please read the following resources before you starting doing anything,
Good luck browsing the internet without UDP ... DNS utilizes UDP as well as many Microsoft system services. It is false that Microsoft blocks or has special rules for UDP.
Best Wishes,
-David Delaune
|
|
|
|
|
Live streaming would be severely limited without UDP you would have to buffer everything packet it up and deal with the TCP nak requests for resend from every user. There is no such thing as multicast on TCP it requires 1 to 1 handshaking. So do you really think your $50 webcam is going to be able to do that to thousands of users 
Poor Skype and an industry we won't talk about
In vino veritas
modified 28-Jun-17 3:22am.
|
|
|
|
|
Hi,
Rick York wrote: Does anyone know of a fundamental issue with W10 and UDP sockets or is it just some setting somewhere they I need to correct?
The high level functionality in the network stack of Windows 10 is basically the same as the network stack in previous Windows releases. Your problem is most likely due to some firewall restriction policy.
Btw, the obligatory "This is not a C++ question" applies here.
Best Wishes,
-David Delaune
|
|
|
|
|
This is the obligatory "where should it go then?" question.
The camera code is written in C. The PC app is C++ and MFC. I don't see a networking or Win10 category so where should it go?
|
|
|
|
|
Rick York wrote: This is the obligatory "where should it go then?" question.
I would suggest the System Admin forum[^] as this is exactly the type of thing they do all day.
Some suggestions:
1.) Use wireshark to see if the packets are being sent. If you see the packets in wireshark... it means they are being physically sent down the wire. This also suggests that your problem is not the program... probably a router or hardware firewall issue.
2.) Bring the camera into your office and connect it directly to your workstation... without any switch or router in the middle. All Ethernet chipsets these days support auto-mdix and do not need a crossover cable. I'm showing my age here...
Best Wishes,
-David Delaune
|
|
|
|
|
What types (if any) of error codes are you seeing?
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
|
|
|
|
|
None at all. Just no response from the cameras. As I mentioned before, they will communicate with the exact same program if it runs on XP or W7. With W10 I can ping them, use FTP and Telnet with them, but UDP sockets will not work.
|
|
|
|
|
Do you see the UDP data on WireShark and it's not being forwarded to your app?
Sorry, I didn't see your previous reply.
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
modified 28-Jun-17 13:41pm.
|
|
|
|
|
I have had no success getting the program to work on W10. I have done a lot of searching and this appears to be a fairly common problem but I haven't found a solution yet. I tried disabling the firewall service and several other things and they didn't help.
The good news is can go back to working on W7. That's good news because I despise W10.
This is also means our systems will be using W7 for the foreseeable future. Oh well.
|
|
|
|
|
Hi,
Rick York wrote: I have had no success getting the program to work on W10.
You do realize that when you see packets in the Wireshark window it means they are being physically sent down the Ethernet cable right?
Best Wishes,
-David Delaune
|
|
|
|
|
It's easy to fix go to the network settings and disable IPv6.
You are sending IPv6 UDP packets
Your device is not IPv6 capable and hence you see the packet on the wireshark but it doesn't respond.
You need to update your code to only do an IPV4 connect.
In vino veritas
|
|
|
|
|
Hi,
I have a MDI project but I wanted to display a window with some info that is not based on my document. I was able to do this and to draw in the window. If I move the window the drawing remains but if I resize it the drawing disappears. I thought the CS_VREDRAW | CS_HREDRAW would take care of this. Also, I don't get the minimize, maximize, close buttons. I'm guessing there are some style conflicts.
Here is the code, it is executed based on a menu selection.
Thanks
CMDIChildWnd * pChild =
((CMDIFrameWnd*)(AfxGetApp()->m_pMainWnd))->MDIGetActive();
CMainFrame* pMainFrm = GetMainFrame();
LPCTSTR ClassName = (LPCTSTR)AfxRegisterWndClass(CS_VREDRAW | CS_HREDRAW,::LoadCursor(NULL, IDC_ARROW),(HBRUSH) ::GetStockObject(WHITE_BRUSH),::LoadIcon(NULL, IDI_APPLICATION));
pMainFrm->Wnd.CreateEx(0, ClassName, "Win",WS_CAPTION | WS_VISIBLE | WS_SIZEBOX | WS_MINIMIZEBOX | WS_MAXIMIZEBOX ,
0, 0, 600,800, pChild->m_hWnd, (HMENU)NULL);
pMainFrm->Wnd.ShowWindow(SW_SHOWNORMAL);
pMainFrm->Wnd.CenterWindow();
CPaintDC dc(CWnd::FromHandle(pMainFrm->Wnd));
modified 27-Jun-17 11:53am.
|
|
|
|
|
al2500 wrote: I don't get the minimize, maximize, close buttons. I'm guessing there are some style conflicts.
Frm MSDN article Window Styles (Windows):
Quote: WS_MAXIMIZEBOX
0x00010000L
The window has a maximize button. Cannot be combined with the WS_EX_CONTEXTHELP style. The WS_SYSMENU style must also be specified.
|
|
|
|
|
al2500 wrote: if I resize it the drawing disappears. I thought the CS_VREDRAW | CS_HREDRAW would take care of this.
If you set these styles then WM_PAINT message will be sent to it after this window has been resized. Do you handle the WM_PAINT message in this class?
Also see Redrawing the Entire Client Area (Windows)
|
|
|
|
|
That is not the problem the MDI classes deal with this automatically.
Unfortunately I only know the raw Windows API not the MFC extension of this but I am sure someone using MFC a lot will know.
The basics are there is an invisible transparent client area in an MDI class and it is that which is responsible for all the default message behaviour including moving the min/max icons to the frame of the parent window. The MDI child window is supposed to call DefMDIChildProc rather than DefWindowProc as it's default message handler.
If you look at a sample when for example I run OpenGL sessions in each MDI the redraws are automatically dealt with.
Native Win32 API OpenGL Tutorial - Part 2[^]
The MFC base class needs to setup the MDIClientArea and change the handlers of the children and that is all that is missing. The process and setup MFC needs to do that is all you need to know and I am sure someone will tell him.
He told you the min/max icons aren't moving to the parent properly so it is definitely the message handler nothing to do with the paint.
In vino veritas
modified 27-Jun-17 12:57pm.
|
|
|
|
|
leon de boer wrote: He told you the min/max icons aren't moving to the parent properly so it is definitely the message handler nothing to do with the paint.
Didn't you read my previous reply?
PS: Please, note what he pointed out: "I don't get the minimize, maximize, close buttons. I'm guessing there are some style conflicts."
|
|
|
|
|
I left it because I understand you have linked the MSDN Page but that is incorrect which I suspected and I tried it 
Download my code and change the MDI child create removing the WS_OVERLAPPEDWINDOW and replace with his flags
if (Child == 0){
Child = CreateWindowEx(WS_EX_MDICHILD,
MDICHILD_CLASSNAME, _T("OpenGL MDI Client"),
WS_CHILD | WS_VISIBLE | WS_CAPTION | WS_SIZEBOX | WS_MINIMIZEBOX | WS_MAXIMIZEBOX,
CW_USEDEFAULT, CW_USEDEFAULT,
CW_USEDEFAULT, CW_USEDEFAULT,
AppMDIClient, NULL, GetModuleHandle(0),
NULL);
}
Code still works perfectly as I suspected from my playing around with MDI because I know what all the flags do. The statement was possibly true historically but current API does not respect that documentation.
So you are technically correct from documentation and he should just use WS_OVERLAPPEDWINDOW but his flags work regardless and isn't the problem.
I am not posting hypothetical I physically checked it because I have working MDI samples and worked thru this stuff.
For the record the current windows API seems to use WS_SYSMENU as a flag to engage the keyboard accelerator keystrokes to the MDI child window. That is all I can find that it does. The current documentation says it controls the "system menu box" which doesn't even exist anymore (all that functionality is under the top left title icon and it ignores the flag). So the MSDN documentation needs a little update. I can imagine some poor new user going what is this "system menu box" they are talking about.
In vino veritas
modified 28-Jun-17 2:53am.
|
|
|
|
|
Thanks all,
I added the WS_SYSMENU and the min, max, close buttons showed up.
I also realized that simply using the CS_VEDRAW, CS_HEDRAW does not enable redrawing during window resizing because there is no code to redraw the window and as was stated I need to respond to the WM_PAINT message.
For now I can just use a fixed size window but this makes me wonder how CWnd direct creation with WM_PAINT support is done. One of my many books made the suggestion that the CWnd MyWnd object be declared in the CMainFrame so that when my code object that paints the window gets destroyed MFC still can communicate with the window. However they did not address how to implement the WM_PAINT.
Is the solution to not allow the code object that does the window painting to exit (and thus is destroyed) until the window is closed? And if so any hints on how this would be done?
|
|
|
|
|
This is why I dislike MFC it mystifies what is actually a simple process. On the windows API itself there is a visibility flag it goes under the name WS_VISIBLE and it tells windows whether to draw a window or not. So a window can exist and even be position on screen but not be visible. There are a number of invisible windows actually at play on the desktop of Windows itself. A hint is what do you think the desktop icons are sitting in.
The rule goes if you create a new window which is visible and it is inserted into a parent that is visible, the standard windows system handlers will issue an initial WM_PAINT message. So it is the act of creating the window with a visible parent that for most windows makes it visible. Windows doesn't care about it being a frame or a window it simply cares what the WS_VISIBLE flag of a child and it's parent.
So you can create an invisible window easy as hell just don't set the WS_VISIBLE flag (try it on your window). Then you will need to use something like the API call ShowWindow to change it to visible.
ShowWindow function (Windows)[^]
That call can also be used to make a visible window go invisible and yes the window will still be there just not visible
You can also upset visibility by fouling up the message handler so it no longer does the default behaviour correctly and you always know that because you will find your paint behaviour is no longer as it should be.
So being visible has absolutely nothing to do with a window existing and invisible windows still exists to the message handlers and you can send message to invisible windows. An invisible window is simply a window that doesn't draw because the visibility flag is wrong or the handler stops it.
The only way to destroy a window is via
DestroyWindow function (Windows)[^]
All the close icons, ALT F4 etc lead to that call if they destroy the window (with the exception an application main window .. it is special and posts a quit message).
So a big difference between a window not being visible and a window being destroyed and don't ever think the two things are the same.
Now the MFC system just puts wrappers around that to try and break it up into a more layman friendly easier to use way. The downside is it sort of obviscates what is really going on with the Windows API.
In vino veritas
modified 29-Jun-17 12:38pm.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
