|
In an EXE I have a Dialog and I have another Dialog
which is started with DoModal()
in another thread using AfxBeginThread.
I want to hide this second Dialog
I have already tried to
ShowWindow( SW_HIDE );
MoveWindow( 0 , 0 , 0 , 0 , false );
But I still see the window on the taskbar.
Can anyone offer any solution.
Thanks,
Sansky
|
|
|
|
|
Cannot test this now, but I think that having the first dialog as the parent of the second one will prevent the latter from appearing on the taskbar.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
Hi There,
I've gota project where I'll be using some dialog bars. I need to implement a tree control on the left side of the main frame that navigates between different screens, kind of like visual studio. I've embedded a CDialogBar member in the CMainFrame class, called create on it. I've got a dialog template where I'll stick a tree control, I guess.
At any rate, I imagine I'm not the first person to try this. Any tips? Any sample code you could recommend?
Thanks,
Aaron
|
|
|
|
|
|
Is it possible to use the Win32 API to setup user groups on Windows NT/2000/XP? If it is could someone please point me at the appropriate API calls.
Thanks for any help you can provide.
Systems AXIS Ltd - Software for Business ...
|
|
|
|
|
|
I have a small problem rendering lines in DirectX (Version 8) with DrawPrimitive, except, that there seems to be no way to set the width of the line. The same applies to points.
Does anybody know a solution!?
Thanks in advance.
Klaus
|
|
|
|
|
Hi,
I've got a CAsyncSocket derived class, trying to implement my own high level protocol.
My command structure consists of a variable length line of text. The kind of thing that a CStdioFile::Readline() likes.
I have an OnReceive() handler which successfully reads the data. To break it into lines, i'm appending my data to a buffer as i receive it, then searching the buffer for \r\n. then, chopping out the left most part of the buffer based on the offset i found the \r\n.
It's all a bit slow though. I'm pretty sure that wanting data line by line is a pretty common need when using CAsyncSocket. How do other people implement this, efficiently?
Jon
Sorry to dissapoint you all with my lack of a witty or poignant signature.
|
|
|
|
|
Your method is essentially the only way to go. Winsock has no built-in support for breaking input into lines. So, if your app is lacking for speed, your only solution is trying to implement this search and cut algorithm more efficiently.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
Just wondering if you have the option of just sending one line at a time.
Some command protocols are blessed with this type of exchange because there's nothing to do till the 1st one line finishes and data is returned to the client, others might use an app level ACK/NACK scheme - either way, each command is atomic.
|
|
|
|
|
Just wondering if you have the option of just sending one line at a time.
In general, no you can't. For connection-oriented sockets (TCP/IP), there's no guarantee at all as to how data chunks are to be received on the other end of the connection. In some cases, data chunks will be coalesced, in others they will be chopped. As a general rule, it is very bad design to assume that "boundary integrity" is preserved in any manner. Having this integrity for a particular network does not mean it'll be kept on another configuration (e.g. with different subnetworks) or even when the conditions on the network change (e.g. high traffic).
For connectionless sockets, aka datagrams (UDP), chunk integrity is preserved. But one has to be careful to not assume some fixed maximum datagram size (it can vary for different stacks and scenarios).
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
Yes, fine, but if the client sends a line and waits for ack from the server before sending another...
|
|
|
|
|
Yes, that'd work. Another solution for preserving chunk boundaries is sending first the length of each chunk. This way the receiver always knows how many bytes to gather for each block. This solution can be mounted as a microprotocol on top of TCP/IP and hidden to the user by some CSocket-like class.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
There is a slightly more efficient approach that you can use, but only if you have control over how the client program generates the message.
What I tend to do is preceed each message with a header. In my particular case, I've been using long integers, in network byte format to be compatible with all types of machines, to indicate the length of the following data.
In my case my program reads the 4 bytes and knows immediately how long the subsequent data is and accordingly waits for the buffer to fill up sufficiently. This saves significant processing as there is no scan necessary to find the end of the message.
However, as I said, all this depends upon whether or not you have control over the client program. If you can modify it to provide the message in this way then it can work. Otherwise your approach is essentially the only one that can be taken.
Good Luck!
Dharminder S. Birdi
|
|
|
|
|
Is anyone having problems trying to debug a MFC app in the new VS .Net? I can create a brand new MFC app under .Net, add nothing to it, compile it, then select "start" and the entire application (.Net) hangs. I have to restart it. The application I'm trying to run does seem to start but it never becomes accessible.
It runs fine if I select the "start without debugging" option.
"Thank you, thank you very much" Elvis.
|
|
|
|
|
I have no problem with it.
Check your debug configuration:Tools-->options
and also your project setting.
Change some of them and see what happend,also if you use win2000 or xp,maybe you login
with username that doesn't have debugging permission.
After all of them,maybe you need to reinstall VS.NET again
Mazy
"So,so you think you can tell,
Heaven from Hell,
Blue skies from pain,...
How I wish,how I wish you were here."
Wish You Were Here-Pink Floyd-1975
|
|
|
|
|
Thanks. I suppose I must have something set wrong somewhere.
"Thank you, thank you very much" Elvis.
|
|
|
|
|
This has probably been solved a hundred times, but I want to be able to write applications that will have a MDI interface but I want to be able to put MFC components sucha Combo Boxes in the view.
For example, If I have a script engine then I want to be able to open a script and have a run/skip/ignore control for each step in that sequence.
Anyone able to help ?
Thanks.
Keith Kenny
|
|
|
|
|
Anonymous wrote:
I want to be able to put MFC components sucha Combo Boxes in the view.
in the last step last of creating your project derive your view class from CFormview
Mazy
"So,so you think you can tell,
Heaven from Hell,
Blue skies from pain,...
How I wish,how I wish you were here."
Wish You Were Here-Pink Floyd-1975
|
|
|
|
|
I have a class with all sorts of functions. in my main application i declare a new variable based on that class. Now i can call functions from that class. BUT when the class is initialised i need to create a sort of a fake Window to catch messages... For this i declared a private HWND variable and when the class initialises i use CreateDialog() to create a fake dialog, but i pass NULL to the MAKINTRESOURCE and all because it doesn't really need to create a dialog. After that, i'm supposed to translate and dispatch the messages with the following code:
while(GetMessage(&messages, NULL, 0, 0))
{
if(!IsDialogMessage(msghandler, &messages))
{
TranslateMessage(&messages);
DispatchMessage(&messages);
}
}
(if msghandler is the fake HWND and messages is a previously declared MSG variable)
now my problem is this:
when i create a new variable from this class, it initialises and it creates the fake HWND but of course it gets stuck in the message loop so my main app doesn't continue running and after i initialise the class i should call other functions from the class but this becomes impossible since the code is still running the message loop.
What do i need to do make the message loop run in the background so i can call other functions from the class. Do i need to use threads or is there a simpler solution. This problem rather took me by surprise... any help is welcome.
Many thanks
Kuniva
--------------------------------------------
God gave man a penis and a brain but not enough blood to make both of 'em work at the same time.
|
|
|
|
|
Your thread can be either pumping messages or doing something else, but not both at a time. So you'd have to move the message loop to a different thread. But this architecture of yours struck me as being really weird. Why do you need a message loop for? Why do you need that fake window for? If you could explain the general architecture of your app then maybe we could give you more valuable advice as to how to lay things out in your code.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
Well, i need the fake window because after the initialisation i call a function from the class that uses
WSAAsyncSelect(sd, msghandler, WM_SOCKET, FD_READ | FD_CLOSE | FD_CONNECT);
where sd is the socket and msghandler the window, so you see i need someplace to send the socket notification messages...
I could also get my main app's HWND but i do not want this because i want to keep it all in the class, i need handlers to the socket events in my class....
i hope this provides a better view to it all, if you want to know anything else just ask me and i will post a reply.
I really dont know how to handle this, maybe i should change the entire structure i ahve no idea...
Thanks
Kuniva
--------------------------------------------
God gave man a penis and a brain but not enough blood to make both of 'em work at the same time.
|
|
|
|
|
OK, now things are clearer... Well, in order to get a separate messga pump where to receive Winsock messages, you have to launch another thread and make this thread create the (let's call it so) Winsock window. I've done this kind of things in the past, so I'm in the position to give you some advice:
In order to have your Winsock window, it is not necessary to create it as a dialog: instead, it's better to register a new window class of your own (this is only done once in the app lifetime):
WNDCLASS wndclass=
{
0,
WinsockWindowProc,
0,
0,
::GetModuleHandle(NULL),
NULL,
NULL,
NULL,
NULL,
"MYWINSOCKWINDOWCLASSORWHAETEVERNAME"
};
::RegisterClass(&wndclass);
Its associated winproc needs only the minimum code to handle Winsock notifications:
LRESULT WinsockWindowProc(HWND hwnd,UINT uMsg,WPARAM wParam,LPARAM lParam)
{
switch(uMsg)
{
case WM_ASYNCSELECT:
...
return 1;
break;
default:
return ::DefWindowProc(hwnd,uMsg,wParam,lParam);
break;
}
}Now your mesagge pumping thread would go like this:
HWND hwndWinsock=NULL;
DWORD WINAPI WinsockThread(LPVOID)
{
hwndWinsock=::CreateWindow(
"MYWINSOCKWINDOWCLASSORWHAETEVERNAME","",0,0,0,0,0,
NULL,NULL,::GetModuleHandle(NULL),NULL);
MSG msg;
while(GetMessage(&msg,NULL,0,0)!=0){
TranslateMessage(&msg);
DispatchMessage(&msg);
}
::DestroyWindow(hwndWinsock);
return 0;
}Launch WinsockThread on initialization time and you're done. To finish the thread use ::PostThreadMessage(idWinsockThread,WM_QUIT,0,0).
I think this brief scheme can help you get started. Good luck.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
um.. how do i create the thread? i'm not very familiar with threads...
Kuniva
--------------------------------------------
God gave man a penis and a brain but not enough blood to make both of 'em work at the same time.
|
|
|
|
|
See your documentation on CreateThread.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
