|
Whenever you get a crash provide:
- The exception info
- The source around the problem with the line highlighted
- The values of any variables of interest (used in the crashing line)
- A stack trace
This is the bare minimum. I also like the some dissassembly around:
- The crash site
- The last transition from your code.
I suggest you post as much of this as you can manage.
Steve
|
|
|
|
|
m_pMainWnd->MessageBox((LPCTSTR)"SockClientThreadFail",NULL,MB_ICONERROR);
threadptr[i]->ipaddr = (LPCTSTR)"192.168.1.4";
Despite numerous explanations that using casts in this way is totally wrong you still use them. You seem determined to ensure that your code will not work.
Use the best guess
|
|
|
|
|
Using an ImageList to load 16 x 16 bitmaps into a toolbar I've been trying to use the bitmaps from that same ImageList for corresponding menu items but I can't get rid of a whiteness around the images. The main code block code below gives the best I can get. Though I can use a IMAGELISTDRAWPARAMS setting the ilDrawParams.rgbBk = GetSysColor(COLOR_MENU) and using ImageList_DrawIndirect which does get rid of the whiteness though the background is then wrong again if the menu item is highlighted - this also seems to be missing the point when is seems the bitmaps can supposedly be drawn transparently anyway. Any suggestions appreciated.
HMENU hMenuMain = GetMenu(hWnd);
HMENU hTestMenu = GetSubMenu(hMenuMain, PORT_MENU_ID);
HIMAGELIST hImageList = ::ImageList_LoadImage(hInst, MAKEINTRESOURCE(IDB_BITMAP1), 16, 0,
RGB(255,0,255), IMAGE_BITMAP, LR_SHARED | LR_LOADTRANSPARENT);
HDC hDCWindow = ::GetDC(hWnd);
HDC hDCDest = CreateCompatibleDC(hDCWindow);
HBITMAP hComapatBitmap = CreateCompatibleBitmap(hDCWindow, 16, 16);
HGDIOBJ hOldDestBmp = SelectObject(hDCDest, hComapatBitmap);
BOOL bDrawn = ImageList_DrawEx(hImageList, 1, hDCDest, 0, 0, 16, 16, RGB(255, 0, 255),
CLR_NONE , ILD_TRANSPARENT);
HBITMAP hRetrievedBitmap = (HBITMAP)::SelectObject(hDCDest, hOldDestBmp);
::DeleteDC(hDCDest);
::ReleaseDC(hWnd, hDCWindow);
MENUITEMINFO MenuItemInfo;
::SecureZeroMemory(&MenuItemInfo, sizeof(MENUITEMINFO));
MenuItemInfo.cbSize = sizeof(MENUITEMINFO);
MenuItemInfo.fMask = MIIM_BITMAP;
MenuItemInfo.hbmpItem = hRetrievedBitmap;
::SetMenuItemInfo(hTestMenu, ID_PORT_EDIT, FALSE, &MenuItemInfo);
::DrawMenuBar(hWnd);
modified 18-Aug-13 4:57am.
|
|
|
|
|
The bitmap needs to contain some indication of transparent background to avoid this problem. I cannot remember exactly how it is identified, but I have a feeling it is some "key" pixel. MSDN or Google may have more information.
Use the best guess
|
|
|
|
|
Richard,
Thanks for the hint, but (as explained below) the problem seems to be with the obtained menu background (white)not being the same colour as the menu (light blue/grey). Thanks anyway.
|
|
|
|
|
I've never found a good solution to this problem. Maybe the HBMMENU_CALLBACK of Vista solves this (I havent tried it) but even in that case it would push up the minimum OS version requirement of your program without any particular reason. I've solved this problem a few times by using ownerdraw menu items but in that case you have to take care a lot of things even if you ignore the look and feel of the OS: like font sizes, underlining the hotkeys in menu item text... Customizing menu items and rawing their icons nicely is a pain in the ass.
I would go with ilDrawParams.rgbBk = GetSysColor(COLOR_MENU). It is not perfect but I wouldn't invest time in owner draw items again for a small cosmetic bug.
|
|
|
|
|
The problem seems to be that the Menu background as obtained by getting MENUINFO.hbrBack isn't the same colour as the menus. I filled my bitmaps that go on the menus with that colour without any icons to see if it all matched. It doesn't, I can see white squares where the icons go against the light blue/grey of the menu (on Windows 8) That white, as seen behind the drawn bitmaps, is presumably what I was trying to remove.
I think I'll take your advice leave it as it is. Thanks.
|
|
|
|
|
I'm still stuck on win7 but I guess what you mean. Since WinXP there are several window managers (like aero, xp-style, old-school,...) and some of these are using extra colors besides the old-school window manager for which the old API was engineered. Sometimes the api lies to your program depending on windows version compatibility settings and the manifest you put into your program. I wouldn't be surprised if there were some fancy APIs to query the REAL colors in another way or with different constants from a newer SDK but I avoided making headaches for myself by polishing GUIs with WinAPI in the last few years...  I guess you have better things to do and customizing the menus is one particular thing that really sucks. In my opinion most of the winapi controls, especially the older ones (including menus) are not good candidates for customization. Things could be worse only if you wanted to customize the menu borders: I've seen code that handled undocumented mouse messages and installed cbt hooks - made me sick and I always started vomiting while reading it... Once I was dreaming about creating a gui skinner lib but I got bored of it halfway when I got to know the sad truth and the mountain of hacks involved...
|
|
|
|
|
Read the MSDN stuff again and found I should have been using GetSysColorBrush(COLOR_MENU); rather then the GetSysColor(COLOR_MENU); I was using which apparently 'returns a cached brush, instead of allocating a new one'. This now does the correct menu background colour.
Could explain why GetSysColor(COLOR_MENU); worked yesterday and not today.
|
|
|
|
|
Thanks for the info! We learn something new every day...
|
|
|
|
|
Hi there everyone.
I have some pretty much basic UDP sockets scenario: my app requests data from server and receives requested data. There is a lot of data so there is a cancellation method as well. When I cancel data receiving and request data again, app not getting FD_READ events anymore. Strange thing is, it is not always the same - sometimes there are a couple of FD_READs, sometimes half of the data could be transmitted before it stops, sometimes - none.
Code itself is basically the same as anywhere on the net and goes like this:
1. Before any receiving, check if FD_READ is set
DWORD dwResult =
::WSAWaitForMultipleEvents(vecHandles.size(), &vecHandles[0], FALSE, dwTimeout, FALSE);
- vecHandles is a vector of event handles, which includes my WSAEVENT for triggering cancellation.
which is done like this:
::WSASetEvent(hEvent);
So now ::WSAWaitForMultipleEvents will return with my event.
2. Check which event we got: if it is read event, then call recv.
if( socket_event_read * pReadEvent = dynamic_cast<socket_event_read *>(pSocketEvent) )
{
WSANETWORKEVENTS nt = { 0x00 };
if( SOCKET_ERROR != ::WSAEnumNetworkEvents(pReadEvent->get_socket(), pSocketEvent, &nt) )
{
if( nt.lNetworkEvents & FD_READ && nt.iErrorCode[FD_READ_BIT] == false )
{
::WSARecvFrom(...);
}
}
}
3. Handle data.
That's it. It all works great if receiving is never cancelled. Otherwise it just stops at some point while waiting for multiple events (::WSAWaitForMultipleEvents) Again, what I mean is:
I hit cancel button and
::WSASetEvent(hEvent); is called, that causes ::WSAWaitForMultipleEvents to return with my cancel event (WSAWaitForMultipleEvents is called in a loop for every incoming data chunk - each one is about 512kb). And then app just stops receiving - it leaves socket as it is, socket is not closed and still alive. Then I hit a button again for app to begin download data again and that is when app stops receiving packets because WSAWaitForMultipleEvents is waiting for fd_read which is never signaled. Then I hit cancel again, - this is handled properly and then again download data - this time data is downloading ok.
This behavior occurs all the time.
I am struggling with this for a couple of days now and got completely no idea what is going on, have searched all the net with no result. I have tried checking, when cancellation is issued, if there is still any data pending on the socket and reading this data - all in vain - it is still remains stuck and not getting fd_read event 
Maybe this issue is related to the fact that app is using one single socket all the time? Maybe it is because server fails and stops sending data? (I have to investigate server as well)
Maybe there is something that you may know and be able to help me with this?
Thanks in advance.
011011010110000101100011011010000110100101101110
0110010101110011
|
|
|
|
|
Could you please post the code of the whole network loop? This info isn't enough. Send also the code/functions (like cancel) that are used to send signal to your network thread and indicate which thread calls what and what does the network thread does in case of a cancel.
BTW, why are you using UPD? You should use TCP to transfer data. In case of UDP you have to implement congestion control and reliability (defense against packet loss) yourself. Is it some kind of real-time data transfer (like audio/video streaming) where data loss is not a problem?
modified 17-Aug-13 13:15pm.
|
|
|
|
|
I think I am going to deal with it myself - code is too big and complicated to post it, or to even take one method from it - it is 1000+ lines custom network framework
I am using UDP for consistency with discovery mechanisms, which I am implementing in app - it should do a lot of networking, pretty fast, without any user intervention - tcp will not allow me to, - it will force a solution where app will have to be configured by user and I cannot allow it to.
I could do discovery only with UDP but I have written huge framework which actually implements TCP partially.
Basically, I am not sure when FD_READ gets signaled? When there is data available or when WSARecvFrom can perform read? This would explain why it is not raised...
I am going to deal with it on my own - it is too complicated
011011010110000101100011011010000110100101101110
0110010101110011
|
|
|
|
|
The main loop of your network thread that handles the send and receive should be relatively small and should be kept together in a small place separated from the other parts of the code. If this critical piece of code is not coupled well separated from your higher level logic, then you should refactor it. This piece of code should handle just raw outgoing and incoming packets on the network thread and all the logic should be implemented separately on top of this layer. A low-level data recv/send loop implementation should be around 100-200 lines of code and all it knows is sending bytes/packets from your send queue, receiving them into a recv queue (and notifying your high level handlers) and exiting when your application exits.
if( socket_event_read * pReadEvent = dynamic_cast<socket_event_read *>(pSocketEvent) )
{
WSANETWORKEVENTS nt = { 0x00 };
if( SOCKET_ERROR != ::WSAEnumNetworkEvents(pReadEvent->get_socket(), pSocketEvent, &nt) )
{
if( nt.lNetworkEvents & FD_READ && nt.iErrorCode[FD_READ_BIT] == false )
{
::WSARecvFrom(...);
}
}
}
For example here your application logic and the a part of your raw network data receiver logic is already mixed that is bad and dynamic_cast is always the indicator of some hacks and bad OO design that needs refactoring. We don't even know when does that dynamic_cast result in a non-null pointer... It seems that you have a big bunch of refactorable code that you will be fixing till the end of your life without a rewrite (and it is worth rewriting stuff... )
BTW, there is another thing that came to my mind regarding WSAWaitForMultipleEvents: FD_READ is level triggered but FD_WRITE is edge triggered and many guys get confused of this. This means that waiting for an FD_READ is safe even if you wait for it twice without reading anything from the socket. The event isn't cleared until data is available for read in the recv buffer of the socket. But FD_WRITE is edge triggered: If you receive an FD_WRITE event then you must assume that FD_WRITE is set until your write fails with EWOULDBLOCK. Receiving an FD_WRITE event clears the FD_WRITE event immediately and it will be set again only when the send buffer of the socket transitions from full to non-full next time. If you try to wait for an FD_WRITE without writing all the available buffer space by receiving EWOULDBLOCK then you will wait for FD_WRITE forever! Depending on how you handle WSAEventSelect and WSAWaitForMultipleEvents your logic can get stuck in many different ways if you don't handle this well.
EDIT: Besides the wakeup event there should be a lock/critical_section as well and these should be used together well along with the shared data (like cancel flag). My loop often got stuck in initial/new network code by screwing up the usage of these or the communication between threads somehow.
modified 17-Aug-13 14:27pm.
|
|
|
|
|
Thanks for your suggestions
Well, I knew about fd_write thing 
Part about critical section got me thinking for sure - that is something I haven't considered in current implementation.
Anyways, thanks very much, I need a moment to think about all this.
011011010110000101100011011010000110100101101110
0110010101110011
|
|
|
|
|
|
I can use DirectShow to connect to a device ( source) , for example audio, I can process the audio “steam” , or not, and “render it to audio device (sink) or GUI.
Or I can use DirectSound to do the same.
So what are the relations between these DirectX “processes” , is one a subset of the other or what?
Thanks for educating me, even if this is not pure C / MFC question.
I do appreciate your time.
Cheers Vaclav
|
|
|
|
|
|
Just found DirectSound API used as audio renderrer in DirectShow graph, hence DirectShow is on first IMHO
|
|
|
|
|
hello;
I tried to write a function that calculates the harmonic average as follows:
long double Harmonique(long double *t,int l)
{
long double s=0.0;
for(int i=0;i<l;i++)
{
if(t[i]==0){
printf("error!!!");
s +=1.0/(1+t[i]);}
else s +=1.0/t[i];
}
return l/s;
}
the console I have this error -1.#IND00 .
what is the origin of this error ?
cordialy
|
|
|
|
|
what are the values of 'l' and 's', when you hit this line:
return l/s;
|
|
|
|
|
I think you should check address of pointer and length of array
|
|
|
|
|
I have checked on visual studio 2010 , you can check again
#include <iostream>
#include <stdio.h>
using namespace std;
long double Harmonique(long double *t,int l)
{
long double s=0.0;
for(int i=0; i<l; i++)
{
if(*t == 0)
{
printf("error!!!");
s +=1.0/(1+(*t));
}
else
{
s +=1.0/(*t);
}
t++ ;
}
return l/s;
}
int main()
{
long double arr[] ={1,5,5,7,43};
long double temp = Harmonique(arr ,5);
cout << temp <<endl;
return 0;
}
3.19262
Press any key to continue . . .
Thanks
Thong Le Trung
|
|
|
|
|
Here, I found the solution. the * t I used in "main" was of type int, so there was a problem of division by zero.
thank you for example and help.
|
|
|
|
|
I am sorry , I see error for you .
I have a example , i hope this example will help you.
What will be output of the following program?
#include<stdio.h>
int main(){
float a=0.7;d
if(a<0.7){
printf("C");
}
else{
printf("C++");
}
return 0;
}
EXPLANATION
Output:
Turbo C++ 3.0: c
Turbo C ++4.5: c
Linux GCC: c
Visual C++: c
Explanation:
0.7 is double constant (Default). Its binary value is written in 64 bit.
Binary value of 0.7 = (0.1011 0011 0011 0011 0011 0011 0011 0011 0011 0011 0011 )
Now here variable a is a floating point variable while 0.7 is double constant. So variable a will contain only 32 bit value i.e.
a = 0.1011 0011 0011 0011 0011 0011 0011 0011 while
0.7 = 0.1011 0011 0011 0011 0011 0011 0011 0011 0011 0011 0011....
It is obvious a < 0.7
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
