|
RockyJames wrote: value in first editbox has to updated based on the interval specified in second editbox.
void CYourDlg::OnDeltaposSpin1(NMHDR *pNMHDR, LRESULT *pResult)
{
LPNMUPDOWN pNMUpDown = reinterpret_cast<LPNMUPDOWN>(pNMHDR);
if(m_strEdit2.GetWindowTextLength()>0)
{
CString s;
m_strEdit1.GetWindowText (s);
int i=atoi(s);
CString t;
m_strEdit2 .GetWindowText (t);
int j=atoi(t);
pNMUpDown ->iDelta =j;
CString u;u.Format ("%d",i+j);
m_st rEdit1.SetWindowText (u);
}
else
{
CString x;
x.Format ("%d",pNMUpDown ->iPos );
m_strEdit1.SetWindowText (x);
}
*pResult = 0;
}
In On InitDialog of your dialog you can put:
CWnd *wnd=GetWindow (IDC_EDIT1);
m_Spin.SetBuddy (wnd);
m_Spin.SetRange (0,200);
m_strEdit1.SetWindowText ("0");
Let me know if this suits your needs now or even if there does exist some problem just inform me back...
-- modified at 2:15 Saturday 23rd September, 2006
Somethings seem HARD to do, until we know how to do them.
_AnShUmAn_
|
|
|
|
|
When i click..up arrow of the..spincontrol value has tobe increased and when i click down arrown value has to be decreased in first edit box,but there in both cases..value is increased...
|
|
|
|
|
Put m_strEdit2.SetWindowText("1"); in On Init dialog.
In OnDeltaPos.... add these lines.
UDACCEL updown;
CString t;
m_strEdit2 .GetWindowText (t);
int j=atoi(t);
updown.nInc =j;
updown.nSec =1;
m_Spin.SetAccel (1,&updown);
CString str;
str.Format ("%d",pNMUpDown ->iPos );
m_strEdit1.SetWindowText (str);
I haven't tested the code...
Somethings seem HARD to do, until we know how to do them.
_AnShUmAn_
|
|
|
|
|
still it is not working properly..frined..
|
|
|
|
|
What do you want,exactly?
You have two editboxs and a spin control that it sets to 0..200 then?
|
|
|
|
|
Hello everyone!
OK, I have a few files, and there's one that causes problems (MapHandling.h ). No matter what I declare in it, it tells me it's already dfined in Game.obj (probably Game.h and Game.cpp )... And sometimes twice, like here:
1>MapHandling.obj : error LNK2005: "void __cdecl Hai2u(void)" (?Hai2u@@YAXXZ) already defined in Game.obj<br />
1>MapHandling.obj : error LNK2005: "struct SDL_Surface pwnz" (?pwnz@@3USDL_Surface@@A) already defined in Game.obj<br />
1>Main.obj : error LNK2005: "void __cdecl Hai2u(void)" (?Hai2u@@YAXXZ) already defined in Game.obj<br />
1>Main.obj : error LNK2005: "struct SDL_Surface pwnz" (?pwnz@@3USDL_Surface@@A) already defined in Game.obj<br />
1>..\Release/War Game.exe : fatal error LNK1169: one or more multiply defined symbols found
Here's the file:
<br />
<br />
#ifndef _MAPHANDLING_H_<br />
#define _MAPHANDLING_H_<br />
<br />
#include "Includes.h"<br />
<br />
void Hai2u();<br />
<br />
SDL_Surface pwnz;<br />
<br />
#endif // _MAPHANDLING_H_<br />
I have include guards on all header files (triple-checked... probably decatriple...). Also note, if I include the file in Main.cpp instead of Game.h , it causes no problems... Anyone know what could possibly be wrong here? Thanks!
Windows Calculator told me I will die at 28.
|
|
|
|
|
The pwnz variable will be declared globally in each cpp file you include MapHandling.h. There's 50% of your errors. Why it complains about Hai2u() , I really don't know. Where is the function body located?
--
A Stern Warning of Things to Come
|
|
|
|
|
|
Include guards will only guard against multiple inclusions of the same header file in a single .cpp-file.
When the compiler runs, it compiles your .cpp-files, one by one. The compilation process is divided into two phases: preprocessing and C++ compilation. The preprocessor expands all preprocessor directives (#include is one such directive) before it passes the preprocessed source code to the compiler, which in turn generates object code.
When all files have been compiled, the linker comes into play. The linker will join all the object code files produced by the compiler, into a single file (.exe, .dll).
Now that you know the basics of the compilation and linking process, it will not be hard to understand why the include guards cannot help you in the case of pwnz . Suppose we have this include file:
#ifndef __INC_H__
#define __INC_H__
int x;
#endif And a source file:
#include "inc.h" and a second source file:
#include "inc.h" .
- The preprocessor processes the file src1.cpp file. It will replace the #include-line with the contents of inc.h. The net effect of this would be a single line in src1.cpp, declaring an int variable with name x. No problems so far.
- The preprocessor sends the processed code to the compiler, which sees the variable declaration. No problems so far. An object code file is produced: src1.obj
- The preprocessor processes the file src2.cpp. As with src1.cpp, its contents will be the same (because it includes the same include file). No problems so far.
- Same thing here as in 2). The compiler sees the variable declaration. Since src1.cpp and src2.cpp are compiled independently, there is no name collision. The variable declared in src1.cpp is not seen by the compiler in src2.cpp. No problems here either. src2.obj is produced.
- All source files have been compiled, so it's time for the linker. The linker examines all object files before it attempts to join them into an .exe-file. What it looks for is to make sure that names are not colliding. In this case, the linker will see that both src1.obj and src2.obj declares a variable with the name x. That is an error, because x is no longer unique - which memory location does x refer to? It can be one of two - and that is something the linker does not like! That is also the error you had in your project.
If you keep in mind that the linker doesn't like ambigous names, and that #include directives are basically "copy'n'paste" operations, you won't run into these problems. If you want to share a variable between two or more source files, you should do something like this:
#ifndef __INC_H__
#define __INC_H__
extern int x;
#endif // __INC_H__ And:
#include "inc.h"
int x; and finally
#include "inc.h" The actual declaration is done in only one source file. The "extern" keyword is a heads up for the compiler that the variable name is reserved, and that it is located in some source file. The compiler then puts a filler value in each instance which you use the variable x. The linker will then fill in the filler value in each instance with the real location of x (in this case, the x that is declared in src1.cpp).
A final note about the inclusion guards. Since the compiler and preprocessor process each source file separately, any #define made during the processing of one source file (or any of its included files), are "reset" before the next source file is processed.
I hope I made sense. Good luck with your project!
--
A Stern Warning of Things to Come
|
|
|
|
|
|
That'll work. You don't need the keyword extern for functions, as function prototypes does the same thing as an extern variable declaration - it tells the compiler to use a filler value until link time.
I'm curious though. Why did you declare an array of only one element?
--
A Stern Warning of Things to Come
|
|
|
|
|
Jörgen Sigvardsson wrote: That'll work.
Nope...
1>MapHandling.obj : error LNK2005: "void __cdecl MapHandling::LoadTiles(void)" (?LoadTiles@MapHandling@@YAXXZ) already defined in Game.obj<br />
1>MapHandling.obj : error LNK2005: "struct MapHandling::TileFile * MapHandling::Tilesets" (?Tilesets@MapHandling@@3PAUTileFile@1@A) already defined in Game.obj<br />
1>Main.obj : error LNK2005: "void __cdecl MapHandling::LoadTiles(void)" (?LoadTiles@MapHandling@@YAXXZ) already defined in Game.obj<br />
1>Main.obj : error LNK2005: "struct MapHandling::TileFile * MapHandling::Tilesets" (?Tilesets@MapHandling@@3PAUTileFile@1@A) already defined in Game.obj<br />
1>..\Release/War Game.exe : fatal error LNK1169: one or more multiply defined symbols found
ThatsAlok wrote: try rebuild all!
Nope...
Jörgen Sigvardsson wrote: I'm curious though. Why did you declare an array of only one element?
'Cause there'll be more later...
Any more ideas? Thanks!
Windows Calculator told me I will die at 28.
|
|
|
|
|
What's in Includes.h?
--
Fun for the whole family - except grandma and grandpa
|
|
|
|
|
Just C++ and SDL stuff:
<br />
#include <iostream><br />
#include <string><br />
#include <stdlib.h><br />
#include <time.h><br />
#include <vector><br />
using namespace std;<br />
<br />
#include "SDL.h"<br />
#include "SDL_image.h"<br />
Thanks!
Windows Calculator told me I will die at 28.
|
|
|
|
|
try rebuild all!
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
Support CRY- Child Relief And you
|
|
|
|
|
the following code is from the examples on the book
[code]
CPen pen (PS_SOLID, 0, RGB (192, 192, 192));
CPen* pOldPen = dc.SelectObject (&pen);
//do some drawing staff here
dc.SelectObject (pOldPen);
I know once I create a pen, I can do some drawing staff, but why should I add "CPen* pOldPen = dc.SelectObject (&pen)" and "dc.SelectObject (pOldPen)" here? what's the use of that?
|
|
|
|
|
It's called restoring the DC to its original state.
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
sorry, what is that mean? could you explain it a little detailed?
what is the difference if I had not use it?
|
|
|
|
|
bloodwinner wrote: what is the difference if I had not use it?
You would get a "resource leak" (a GDI handle would be lost, and if your app runs for a long time, this leak would accumulate, which isn't good - leaks like this can easily crash Win9x for example). Basically, if a GDI object such as a pen, brush or font is still selected into a DC when it is destroyed, you will get a leak:
void Draw(CDC& dc)
{
CPen pen;
pen.CreatePen(PS_SOLID, 2, RGB(255,0,0));
dc.SelectObject(&pen);
...
}
To avoid this, do as your sample code shows (save the previous object when calling SelectObject ), or save/restore the DC state like this:
void Draw(CDC& dc)
{
int nState = dc.SaveDC();
CPen pen;
pen.CreatePen(PS_SOLID, 2, RGB(255,0,0));
dc.SelectObject(&pen);
...
dc.RestoreDC(nState);
}
Last modified: 11hrs 24mins after originally posted --
Kicking squealing Gucci little piggy.
|
|
|
|
|
That type of restore is more costly if I recall correctly. SaveState() saves everything. So, if you're only using a brush for instance, SaveState() will give you lots of overhead. On the other hand, CPU cycles aren't really a scarce resource these days..
--
A Stern Warning of Things to Come
|
|
|
|
|
SaveState()???
I have used SaveDC() and RestoreDC() but never SaveState() and RestoreState(). Are you guys mistaken on the name or is this a function I am not aware of?
|
|
|
|
|
Nah, Rob and I are just senile, and meant SaveDC/RestoreDC.
(Unless Rob really do know about some undocumented funcions )
--
A Stern Warning of Things to Come
|
|
|
|
|
Ooops. Yes, I meant SaveDC/RestoreDC - it was late when I made the post!
Kicking squealing Gucci little piggy.
|
|
|
|
|
Me too I wrote a program with SaveDC and RestoreDC
|
|
|
|
|
How do I determine which CSlider is sending a message?
1. Dialog CExoSliderDlg with two sliders and two edit boxes.
2. Both sliders work, and both deliver nPos which is used to update edit box variable m_SliderValue.
3. I want IDC_SLIDER to update m_SliderValue
4. I want IDC_SLIDER2 to update m_SliderValue2.
5. I think CScrollBar* pScrollBar can tell me which slider is active.
6. I don't know how to determine which slider is active. How to do it?
IDC_SLIDER_VALUE CString m_SliderValue
IDC_SLIDER_VALUE2 CString m_SliderValue2
IDC_SLIDER CSliderCtrl m_Slider
IDC_SLIDER2 CSliderCtrl m_Slider2
void CExoSliderDlg::OnHScroll(UINT nSBCode, UINT nPos, CScrollBar* pScrollBar)
{
if(nSBCode == SB_THUMBPOSITION)
{
m_SliderValue.Format("%ld", nPos);
UpdateData(false);
}
else
{
CDialog::OnHScroll(nSBCode, nPos, pScrollBar);
}
}
|
|
|
|