|
Does this search help?
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
|
|
|
|
|
hehe ,let me see tomorow,tonight is too late (in asia)
|
|
|
|
|
|
I tried replacing the toolbar in my application with a 24 bit color toolbar bitmap. Since I edited the original toolbar bitmap image the buttons are all in the right place, however, saving the image as a 24 bit bitmap makes it look (in the application) hideous.
Is there any way to simply increase the resolution of the toolbar bitmap as it is rendered in the application ? (from 4 bit to 8 bit color ?)
"One of the Georges," said Psmith, "I forget which, once said that a
certain number of hours' sleep a day--I cannot recall for the moment how
many--made a man something, which for the time being has slipped my
memory."
|
|
|
|
|
|
Hi people , 
I´m working on an application that must draw some graphics using OpenGL. The aproach I´m using is to
initialize the window ,to set graphics mode and to set render context for OpenGL at the mainthread < InitInstance() > and then call a thread that must keep rendering frames until the end of the program.
well... I noticed that everithing works fine at the main thread ( including GL´s drawing calls)but when I make the same calls inside the thread , they have no efect on the window.
I can´t understand  , because all the variables I use inside the thread are global. 
Can you help me ?
![Rose | [Rose]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/rose.gif)
Ps: 1) I created the thread using CreateThread.
2) My project is a simple win32 application => WinMain , InitInstance , Createwindow , winProc , etc...
|
|
|
|
|
You can only update the window from the thread that created it, so you'll have to create the window inside the thread that's going to be doing the OpenGL rendering.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
I do this in one of my OpenGL window classes as well.
First you must/should do the following when:
registering the window class:
- add CS_OWNDC | CS_HREDRAW | CS_VREDRAW styles
- set hbrBackground to NULL
creating the window:
- add WS_CLIPCHILDREN | WS_CLIPSIBLINGS styles.
using the window:
- handle WM_ERASEBKGND and return true
- handle WM_WINDOWPOSCHANGED when !(flags & SWP_NOSIZE) to update the viewport
There can be any number of things wrong.
A couple of the more common are:
- the DC and RC must stay current to the rendering thread while rendering (i.e. the app thread can't use the DC/RC without some syncing with the render thread). generally you get the DC right after the window is created, get an RC for the DC, and keep hold of both until the window is destroyed.
- because the window is created by the app thread it gets the WM_PAINT msg. at some point before you return (true) you should call ::ValidateRect() to clear the WM_PAINT msg. if you don't call this, and return false, the default paint handler will paint with the background brush.
...cmk
Save the whales - collect the whole set
|
|
|
|
|
The Problem was that I needed to make a current rendering context inside the thread:->.
I created a window for the aplication , Initialized OpenGL on the aplication , and created a rendering context inside the thread. 
It works fine now , and I´m geting 150 frames /second  !!!!
|
|
|
|
|
My program suddenly stops working when it hits the third cout statement in my program. Has this ever happened to anyone before? Any solutions? 
|
|
|
|
|
|
int main()
{
int numerator, denominator;
cout<<"--Reducing Fractions Program--\n";
cout<<endl;
="" numerator="" entry
="" cout<<"enter="" the="" numerator:="" ";
="" cin="">>numerator;
//denominator entry
cout<<"Enter the Denominator: ";
cin>>denominator;
cout<<"Starting Reduce\n";
-------------------------------------------------
I am using the iostream library
I get an abort before the line: cout<<"Starting Reduce\n";
|
|
|
|
|
Anonymous wrote:
I get an abort before the line: cout<<"Starting Reduce\n";
If that statement is removed, does the error persist?
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
|
|
|
|
|
I figured it out. Thanks Guys.
|
|
|
|
|
How about sharing it with the rest of us?
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
|
|
|
|
|
There is no problem with the code check out the range of numerator and denominator ur providing.
|
|
|
|
|
The numerator and denominator were within range, but the debugger was stopping the program from working propperly.
|
|
|
|
|
Hi,
I want to do something like this, but not sure what the behavior will be:
<br />
class A<br />
{<br />
virtual void Init(int width, int height) = 0;<br />
};<br />
class B<br />
{<br />
virtual void Init(int width = 640, int height = 480);<br />
};<br />
class C<br />
{<br />
virtual void Init(int width = 800, int height = 600);<br />
};<br />
Does this mean if I say:
<br />
B *var1 = new B();<br />
A *pvar1 = &myB;<br />
pvar1->Init();
pvar1->Init(320,240);
This will call the correct function?
|
|
|
|
|
The easiest way to answer this type of question is to set a breakpoint within each Init() method and see how/when they are called.
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
|
|
|
|
|
I assume that B derives from A. In that case, it will call the correct function (the one in B).
Default parameters are only significant at the calling point. If you don't provide parameters, the compiler puts them in for you. So pvar1->Init() will get compiled as pvar1->Init(640, 480); and will call B's implementation.
Regards
Senthil
_____________________________
My Blog | My Articles | WinMacro
|
|
|
|
|
|
This is not a good idea. Good programming practice is to always use the same default values for overridden methods, or better yet, don't use default values for virtual methods. Have you tried to compile this? I don't think it will compile. The compiler doesn't know that pvar1 is actually of type B, so it will check the parameters against the Init method in class A, and fail, because there are no defaults. The defaults for the method in class B will only be used if you call the method through a variable of type B.
Generally, if you don't know what will happen, don't do it, because it will make someone else's life difficult when they come to maintain it and also don't know what will happen.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
Hi All
I have run out of ideas can anyone help me.
I have created a extension DLL for a Patient selection dialog. When the dialog opens it initializes a list with with patient details. The user can then select one of the patients and the dialog closes and then the program can query the dialog before its destruction to get the index of the patient who was selected.
void CTestApp::OnFileOpen()
{
CLantisPatientSelectDlg dlg;
if(dlg.DoModal() == IDOK){
m_nPatID1 = dlg.GetPatID1();
}
}
To try and be tidy in the OnOK() member function of my class derived from CDialog I delete all of the list.
void CLantisPatientSelectDlg::OnOK()
{
int nIndex;
CPatientDetails *pPatientDetails;
CListCtrl *pList = (CListCtrl *)GetDlgItem(IDC_PATIENTLIST);
nIndex = pList->GetSelectionMark();
if(nIndex != -1){
POSITION pos = m_lpPatients.FindIndex(nIndex);
if(pos != NULL){
pPatientDetails = m_lpPatients.GetAt(pos);
m_nSelectedPatID1 = pPatientDetails->m_Pat_ID1;
}
} else {
m_nSelectedPatID1 = -1;
}
// Get any background list loading to terminate
m_bTerminateLoad = true;
::WaitForSingleObject(m_hListLoadingThread,INFINITE);
DeletePatientList();
CDialog::OnOK();
}
void CLantisPatientSelectDlg::DeletePatientList()
{
CPatientDetails *pPatientDetails;
POSITION pos = m_lpPatients.GetHeadPosition();
while(pos != NULL){
pPatientDetails = m_lpPatients.RemoveHead();
delete pPatientDetails;
pos = m_lpPatients.GetHeadPosition();
}
}
Now all of this seems to work alright until it comes to the end of the OnFileOpen() function at which point the instance of the dialog goes out of scope and the system deletes it. At this point the list which was cleared before and had 0 elements now seems to have a count of -1 (0xFFFFFFFF) and the routine to get rid of it crashes.
I am using a different header file for the DLL'ed Dialog in the application which only lists the functions that have been exported.
Any ideas??
|
|
|
|
|
Delete the m_lpPatients list in the dialog's destructor. That way it gets cleaned up no matter if the OK, Cancel, or X button is used.
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
|
|
|
|
|
Yeah I agree with you and I was doing that but it doesn't seem to be the problem. When it comes time to destruct the instance of the dialog the list, which is empty by this time, appears to have been corrupted in some way and hence can't delete properly.
I have just noticed something else. In the code section
void CTestApp::OnFileOpen()
{
CLantisPatientSelectDlg dlg;
if(dlg.DoModal() == IDOK){
m_nPatID1 = dlg.GetPatID1();
}
}
In my testing before posting I didn't have the
m_nPatID1 = dlg.GetPatID1();
line and hence my code went on to destruct the dlg instance immediately. Now with this code a new failure mode is occurring along with the old one which is generated when you Cancel out of the dialog. In the line highlighted above the dlg.GetPatID1() function runs correctly and returns an int but an access violation occurs when this return value is copied to the m_nPatID1 variable.
I must be doing something silly. I just can't see it.
Andrew
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
