|
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.
|
|
|
|
|
Hi,
I know LDPC decoding logic but i don`t have knowledge in Data Structure. Please help me How to proceed LDPC Decoding Using Data Structure in C ? Please teach me in writing coding step by step.
In that process i have been provided with a H matrix,code word like [c1, c2, c3, c4, c5, c6] =[1 0 1 0 1 1].
The received word is r=[X 0 1 X 1 1], where X = missing bits. c1 and c4 are missing bits, i need to find missing bits using tanner graph.
In tanner graph, there are two nodes : Check Nodes and Variable Nodes
#Variable-nodes: Correspond to bits of the codeword or equivalently, to columns of the parity check matrix.
There are n v-nodes
#Check-nodes: Correspond to parity check equations or equivalently, to rows of the parity check matrix. Also known as constraint nodes.
There are m = (n-k) c-nodes.
STEPS :
c4 bit is recovered first and then c1 bit is recovered. Total 2 iterations are used.
1. Messages are passed from variable nodes to check nodes. At check nodes they are processed and the results are stored
using the constraint c3^c4^ c6=0, we calculate the value of c4.
2. Update the values at variable nodes, Messages (value of c4 ) are passed from check nodes to variable nodes
3.Updated messages are again transferred from variable nodes to check nodes.
Using constraint: c1^c2^c3^c4=0
Value of c1 is calculated
4. Values are updated at variable nodes, Message (value of c1) is passed from check nodes to variable nodes
Finally, missing bits are identified
|
|
|
|
|
|
Can I ask do you actually know how to program in C at all?
With your last question about tanh and now this I am really suspecting not or you are a student and this is homework for like a communications unit.
All you have to do is translate that text to code (start with pseudocode if you like).
Here let me do step 1 and solve c4 it's 1 line of C code
if (c3^1^c6 == 0) c4 = 1; else c4 = 0;
That assumes c3,c4,c6 etc are int's or something I can run the logical operator on but you haven't even told us that detail but you want us to write some code. For now lets just treat it as pseudocode.
So code written that is the solution to step 1, we have c4 evaluated.
Now you try Step 2 it is a simple shuffle of c4 from above back into the nodes but we don't know what you have the data in. So how about you have a crack at writing the code and show us. Even if it's not working I can at least see how you have the nodes setup. I don't even care about the types for now just write the variables c4 is adjusting.
Lets give you Step 3.
if (1^c2^c3^c4 == 0) c1 = 1; else c1 = 0;
Step 4 is another simple shuffle just needs some code which will be similar to Step 2 and you then have pseudocode to the entire problem.
In vino veritas
modified 27-Jun-17 21:19pm.
|
|
|
|
|
Thanks leon de boer. As per your guidelines, i will start writing the codes.
|
|
|
|
|
Hi,
First of all genuine thanks to all that contributed to my previous queery. It was really helpful, and moved things along.
I wrote a method: MkRvaPrt() that takes an rva, and maps it successfully to the file location, rather than to the memory location where the object would be after using LoadLibrary();
Sections in a PE File are used where a block of binary data is mapped to a file location other than the offset in the file.
What the MkRvaPtr() function does is, it checks whether the virtual address is within the ranges of any of the Section Headers, (irrespective of name), and, if so calculates the adjustment, and returns a pointer into the file. If it does not point into a section, it returns the rva offset into the File.
This all works smooth, but sets the stage to several questions.:-
Sometimes, the rva found, already points at the required data, at other occasions, it has to be converted with MkRvaPtr.
e.g.:
I need to use MkRvaPtr to get the name of each Import Module, but the list of "PtrsToImportNames" needs no such translation.
Does this table consist of relative offsets to itself? If so, How was I to know!
Kind Regards,
Bram van Kampen
modified 26-Jun-17 21:10pm.
|
|
|
|
|
Hi, I want to fill out a char array with space.
like:
memset(msgArray, '*', 100);
but '*' should be a Space key.
|
|
|
|
|
memset(msgArray, ' ', 100);
memset(msgArray, #32, 100);
or a myriad of others
In vino veritas
|
|
|
|
|
Thanks, ' ' and 32 work.
in fact, it's snprintf() reason. snprintf seems fill out the gap in a string with '\0'.
modified 25-Jun-17 10:06am.
|
|
|
|
|
I find this question a bit mysterious, if you had tried the obvious thing it just should have worked.
The "obvious thing" is:
focusdoit wrote: '*' should be a Space key.
.. literally just replace '*' by ' '.
|
|
|
|
|
in fact, it's snprintf() reason. snprintf seems fill out the gap in a string with '\0'.
the code like:
memset (msgArray, ' ', 100);
snprintf (msgArray, 2, "%d", 1);
snprintf (messageArray+10, 33, "%s", "main");
I assume the string should output like:
1 main
but debugged it. it is : 1,\0, ' ', ' ', .. main, \0, ..
|
|
|
|
|
Well snprintf terminates its output with a \0, which is typically useful (it would be a bit dangerous if it didn't), you can just overwrite that \0 with a space.
|
|
|
|
|
Here's the prototype for the function :
int _snprintf( char *buffer, size_t count, const char *format, ... );
I usually use it like this :
const size_t bufferSize = 127
char buffer[bufferSize+1] = {0};
_snprintf( buffer, bufferSize, "%3d %s", index, yourString );
You can combine the _snprintf calls into one since they are going into the same memory buffer.
|
|
|
|
|
That is because you are doing it all wrong you either join them all up in one sequence or move the first pointer along
They are designed to be used a completely different way
Single line:
snprintf (msgArray, sizeof(msgArray),"%d%s", 1,"main");
Concat sequence (with buffer safety):
char *cur = &msgArray[0];
char *end = &msgArray[sizeof(msgArray)-1];
cur += snprintf(cur, end-cur, "%d", 1);
snprintf(cur, end-cur, "%s", "main");
In vino veritas
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
