|
I think then that the connection is closed and needs to be reconnected.
That would explain the NOTSOCK error since the socket became invalid at some point.
That also explains the WSAECONNRESET error. When you get that error the connection is closed.
That means you should close the socket and reconnect.
"Great job, team. Head back to base for debriefing and cocktails."
(Spottswoode "Team America")
|
|
|
|
|
The NOTSOCK error is because somewhere in your code you are closing the socket handle.
If the wireless connection gets down, in a period of time you will receive de connection reset error when the system detects the broken connection but the socket handle still remains valid so you should not receive notsock errors unless you closed the handle.
Best regards, Mauro.
|
|
|
|
|
Good point.
Something is happening to the socket somewhere, but we haven't seen any code so who knows?
Thanks!
Mark
"Great job, team. Head back to base for debriefing and cocktails."
(Spottswoode "Team America")
|
|
|
|
|
|
Thanks for the tip.
Best regards
|
|
|
|
|
Hi,
In order to avoid naming conflicts between different libraries, and avoiding changing names to functions, is there any way to add some "prefix" or suffix to the decorated name that the compiler generates, via, for e.g., a #pragma?
I don't believe it is possible, but if it is, please post the answer.
Best regards, Mauro.
|
|
|
|
|
are you in a particuliar need ?
|
|
|
|
|
Hi,
I'm making a personal library for handling images, videos and some other stuff. I use the code of libpng, and libtheora for example.
In theora there is a function named "cpu_init" and I haven't conflicts for now but you see it has a "common" name that can be used in other libraries or by me if I have no deep knowledge of internal functions.
I wish to add the "theora_" prefix to all functions in libtheora to prevent potential conflicts. If there is no way I should change the names manually.
Best regards, Mauro.
|
|
|
|
|
Mauro Leggieri wrote: I wish to add the "theora_" prefix to all functions in libtheora
what about prefixing - like Roger suggested - to prefix with theora:: instead ?
|
|
|
|
|
Not really sure what you're after, but there's a chance that a namespace would satisfy your needs. Have a look here[^].
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
Hi,
Yes it would but namespaces works in C++ and many libraries are in plain C.
Best regards, Mauro.
|
|
|
|
|
if you code in C++, there's no problem... you can import C functions inside it then
what do you think the standard C++ library does with the C runtime functions into the std:: namespace ?
-- modified at 14:30 Tuesday 20th March, 2007
|
|
|
|
|
Each C source files in theora generates a .obj file with the possible conflicting public symbols. Encapsulating inside a C++ object doesn't hide public symbols from original theora compiled object files.
Code is opensource so I can make things like changing function names but I wish to avoid that in order to make updates easily when there are new versions available.
Greetings,
Mauro
|
|
|
|
|
you don't get it.
process in 2 steps.
firstly, generate a library which will present the theora in your namespace.
then, use this "new" library, which won't generate name duplicates anymore, due to the namespace...
|
|
|
|
|
Thanks Toxcct 4 answering.
Can you explain me more detailed?
Imagine I have a C function named myfunc in test1.c
Then test1.lib will contain the module test1.obj that contains the _myfunc public symbol.
On the other side, another function with the same name but in test2.lib
When I link the app with test1.lib and test2.lib the linker gives an error in test2.lib(test2.obj) because _myfunc is already defined in test1.lib(test1.obj)
I didn't find to hide test1.obj from the visibility of test2.obj, no matters if it is inside a .lib
Best regards,
Mauro.
|
|
|
|
|
Hi everybody,
I try to create a modeless dialog in the client area of a MDI application. It should display some data form the app class (not the document). When I create the dialog:
pmyDlg = new CmyDialog;
pmyDlg->Create(IDD_DIALOG_mydlg)
pmyDlg->ShowWindow(SW_SHOW)
it always appear on top of the application, not in the client area of the child frame. I tried things like pmyDlg->Create(IDD_DIALOG_mydlg, theApp.m_pMainWnd) to set a parent for this dialog but it was alway dragable over the whole desktop and was not restricted to the client area.
Can someone send me a hint?
Many thanks.
Cheers,
Frank.
|
|
|
|
|
did you have a look at this[^] ?
|
|
|
|
|
yes, but it doesn't help me because Nishant Sivakumar suggest to use the desktop window as a parent for the modeless dialog. When I do this, the modeless dialog is even more independent of my application.
What I want is a modeless dialog, which behaves like a MDIView but without the overhead of the document. It should be moveable only inside the client area of the application and not on the whole desktop.
|
|
|
|
|
Subclass your childview[of MDI] and create a child[WS_CHILD] dialog on it.
--
======
Arman
|
|
|
|
|
Franken wrote: What I want is a modeless dialog, which behaves like a MDIView but without the overhead of the document.
yuck.
Franken wrote: It should be moveable only inside the client area of the application and not on the whole desktop.
double yuck.
but I'm a good sport.
Can't you create the modeless dialog with the MainFrame as a WS_CHILD of the main frame ? or something similar ?
I think I remember that you can set of the dialog style to do this.
|
|
|
|
|
Maximilien wrote: ...the MainFrame as a WS_CHILD of the main frame ?
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
ok, that was bad! 
|
|
|
|
|
I also thought that it should be possible to set WS_CHILD style but haven't found a way to do this.
|
|
|
|
|
Do you want the MDIFrame window to be the parent or do you want to place the dialog in a
MDIChild frame?
Either way, the dialog needs to be a child and you need to specify the parent in the Create()
call.
You can set the child style in the resource editor, properties, style.
Mark
"Great job, team. Head back to base for debriefing and cocktails."
(Spottswoode "Team America")
|
|
|
|
|
I set the style to child in the dialog editor properties and did the following during the creation of the dialog:
CMainFrame* pFrame = (CMainFrame*)GetMainWnd();
CChildFrame* pChild = (CChildFrame*)pFrame->GetActiveFrame();
CmyDlg* pDlg = new CmyDlg;
pDlg->Create(IDD_DIALOG_myDlg, pChild->GetParent());
pDlg->ShowWindow(SW_SHOW);
This is almost what I wanted but it shows some weird behaviour. When a region of the dialog is covered by another child window this region shows still the part of the child window even if I drag the dialog to another place. It only restores the correct dialog, when I resize the dialog. Is there somewhere a flag like redraw or something?
Many thanks  ,
Frank.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
