|
SetWindowPlacement()
Kuphryn
|
|
|
|
|
That doesn't work either (just tested, it's still ignored), unless I use it after the window has been shown, which means I still get the flickering during startup.
[edit] Ok, I made a couple changes with the queue and got it to maximize, but I still get the drawing issues that I do with ShowWindow(). Now, pardon me while I beat my head against the wall.  [/edit]
Thanks for the reply though.
Jeremy Falcon
|
|
|
|
|
I got rid of the flicker by adding a couple of painting ops (hope it doesn't mess me up down the read as I'm new to OGL).
But, if anyone knows why CreateWindow() doesn't honor WS_MAXMIMIZE for anything but a popup, you'd be my new hero for the day. Either way, thanks for watching me whine. 
Jeremy Falcon
|
|
|
|
|
How is ShowWindow() called? In most applications, ShowWindow() is called *after* you've called CreateWindow(), hence making your window seemingly ignore your flags. In MFC apps, what's passed to the mainwindow's ShowWindow(), is whatever the process has been fed (settings on shortcut, spawning process, etc).
Jeremy Falcon wrote: As such, I'd rather have it maximized before the window is shown rather than after and don't want to go through the trouble of screwing around with the message queue to deal with it.
You don't need to fiddle with WS_MAXIMIZE. Just create the window without the WS_VISIBLE flag. Then call ShowWindow() with SW_SHOWMAXIMIZED. No screwing around with the message queue. 
--
100% natural. No superstitious additives.
|
|
|
|
|
Jörgen Sigvardsson wrote: ShowWindow() is called *after* you've called CreateWindow()
It has to be, otherwise I wouldn't have a valid handle.
Jörgen Sigvardsson wrote: Just create the window without the WS_VISIBLE flag.
Did that. In fact I rarely use that bit for a main window.
Jörgen Sigvardsson wrote: Then call ShowWindow() with SW_SHOWMAXIMIZED.
Did that, except I used SW_MAXIMIZE instead.
Jörgen Sigvardsson wrote: No screwing around with the message queue.
Not always. At first, doing what you just described, it was showing the window, then showed it maximized, and then drawing the OGL scene. There's a small delay during startup because of the processing involved, but it was a three part startup that I could actually watch happen.
So, I thought, why just use the bit in CreatWindow() itself except that didn't work. Hence my post.
Anyway, I got around it by messing with my drawing code, but I would still like to know why in tarnation that style bit didn't work for CreateWindow.
Jeremy Falcon
|
|
|
|
|
Oh, and thanks for the reply. It's the end of the day and I'm getting slow. 
Jeremy Falcon
|
|
|
|
|
|
aafcls wrote: am I missing something
If you are missing knowing how C++ .h and .cpp files and class/function declarations and definitions work then yes, you are missing something.
|
|
|
|
|
it may be best for you to read some books and go through some tutorials instead of getting a quick answer to your problem - this is really fundamental so you should learn the basics before going on with your task
cje
|
|
|
|
|
aafcls wrote: am I missing something in this file, like a declaration or header?
Yes. You need to declare class members when creating the class. I would suggest you search around for a few tutorials on the web to help get you up to speed on this.
If you perfer books, then there are quite a few excellent MFC books out there I can recommend as well.
Jeremy Falcon
|
|
|
|
|
Can you show how to declare this function
whitesky
|
|
|
|
|
I have an application where I want to be able to receive data from a socket at any time and at the same time be able to send data. Is it ligitimate to issue a send()in the main thread while I am blocked on a recv() on the same connection in a different thread?
BCS
|
|
|
|
|
Are you doing asynchronous or synchronous I/O?
"The largest fire starts but with the smallest spark." - David Crow
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
I am doing synchronous I/O.
|
|
|
|
|
Yes, dependent on the protocol and implementation of the remote process.
|
|
|
|
|
Your answer is somewhat obscure. The protocol is TCP/IP. I don't know what significance the remote process has, assuming that the remote process you are referring to is what is on the other side of the connection. Assume for now it is the same configuration on both sides of the connection.
|
|
|
|
|
bcstone wrote: The protocol is TCP/IP.
That is the transmission protocol. I am referring to the application protocol.
bcstone wrote: the data coming from one direction may have no relationship to the data going in the opposite direction.
"may have no relationship" How do you know? There must be a protocol that indicates this correct?Last modified: Thursday, June 29, 2006 10:36:53 AM -- sorry hit the post button before I finished (ooops)
|
|
|
|
|
bcstone wrote: Is it ligitimate to issue a send()in the main thread while I am blocked on a recv() on the same connection in a different thread?
As long as the data isn't interdependent on one another there is no technical issue I'm aware of that says this isn't a problem. If it is, then you should avoid this and/or use semaphores, etc. and marshalling to help keep the data in check.
To use an analogy, you don't want to receive a answer before you send off a question for the answer first.
So, if the data isn't dependent you should be ok, all normal issues like bandwidth, remote connections capped, etc. notwithstanding.
Jeremy Falcon
|
|
|
|
|
Your analogy is correct for a transfer model of question/answer, but in this case, the data coming from one direction may have no relationship to the data going in the opposite direction.
Take for example an implementation of a TCP/IP terminal program where the user types on the screen some information that gets sent over the socket, but the other side at any time, could be sending information to be displayed on the screen unrelated to the information being typed by the user.
I assume your use of the word "dependent" means the answer to the question previously sent. Again, that is not the model used.
Thanks for your feedback. It is appreciated!
B. Stone
|
|
|
|
|
bcstone wrote: I assume your use of the word "dependent" means the answer to the question previously sent. Again, that is not the model used.
Yup. Then you should be ok if that's the case.
Jeremy Falcon
|
|
|
|
|
Yes, it's legitimate. Send and receive buffers are separated, so threading isn't an issue for the IP-stack.
--
100% natural. No superstitious additives.
|
|
|
|
|
Hi All,
I have a list control in report view with slider controls as items.
When I scroll through the list using the mouse wheel or page up and page down, some of the track bars in the slider controls get changed.
Can anyone help me with this problem? I tried using a progress bar but I get the same problem.
|
|
|
|
|
Hi all,
After creating two radio buttons how can
i set which one is checked at boot ?
How can i get/set their check condition ?
TIA,
Desmo16.
|
|
|
|
|
If you are using MFC, you group them (setting the group property on them -- read the MSDN documentation for more details), and then assign a variable to the first one in the group. If you assigned an integer value to it, you would set the integer value to the value of the index in the group. For example, if you have:
IDC_MYRADIO_0
IDC_MYRADIO_1
as the resource names for your radio buttons (make sure they are in sequential order in your resource.h file), and you assing m_iMyRadioValue to represent the data for the radio buttons, you would set m_iMyRadioValue to the corresponding button you want selected:
m_iMyRadioValue = 0;<br />
UpdateData(FALSE);<br />
<br />
m_iMyRadioValue = 1;<br />
UpdateData(FALSE);
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
Desmo16 wrote: i set which one is checked at boot ?
If you are using MFC, use CButton::SetCheck(BST_CHECKED). Otherwise, send the control a BM_SETCHECK message. UpdateData() is the wrong choice here. 
"The largest fire starts but with the smallest spark." - David Crow
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
