|
I thought that you were not able to measure the height.
Anyway looks like GDI+ doesnot have anymeans to do that. You can use PInvoke to find whether a font i strue type or not.
|
|
|
|
|
Rama Krishna wrote:
You can use PInvoke to find whether a font i strue type or not.
You mean use EnumFonts and the callback etc... ?
Damn! All that work just to figure out whether a font is true type!!!
This .NET thingie is sure incomplete!!!
Nish 
Author of the romantic comedy
Summer Love and Some more Cricket [New Win]
Review by Shog9
Click here for review[NW]
|
|
|
|
|
try chaning the charset or language or whatever 
- Roman -
|
|
|
|
|
Nishant S wrote:
raavi
Did someone call? 
/ravi
Let's put "civil" back into "civilization"
http://www.ravib.com
ravib@ravib.com
|
|
|
|
|
I don't know much about fonts, but it sounds to me like either they aren't installed correctly, or you're trying to use characters that don't exist for that font (i.e. english characters for indian fonts). Try using the Character Map utility to determine which characters are actually implemented, and then use those.
---
Shog9
If I could sleep forever, I could forget about everything...
|
|
|
|
|
Shog9 wrote:
don't know much about fonts, but it sounds to me like either they aren't installed correctly, or you're trying to use characters that don't exist for that font (i.e. english characters for indian fonts). Try using the Character Map utility to determine which characters are actually implemented, and then use those.
VOILA!!! That's it. You've hit it right in the middle of the eye ShoggyBoy!!
w00t!!
Shog, remember that quote I made about you being a genius. I forgot the URL and my bandwidth prevents me from using it. Can you please repeat that for me, so I can just say it aloud a few times here.
Man, it's all that salmon he eats!!!
Nish
Author of the romantic comedy
Summer Love and Some more Cricket [New Win]
Review by Shog9
Click here for review[NW]
|
|
|
|
|
To get a string out of the value field from a simple Acccess data base I have seen the following:
strContent = (char *) (_bstr_t) db.m_pRecordset->Fields->GetItem ("Color")->Value;
What if the value stored in there is an integer?
Would it be:
strContent = (int*) (_bstr_t) db.m_pRecordset->Fields->GetItem ("Color")->Value;
I am not familiar with _bstr_t so am not sure. Another thing I saw was Value.lVal, Value.bstrVal, etc but dont recall where I saw it and what its use is specifically.
Thanks for helping,
ns
|
|
|
|
|
nss wrote:
strContent = (char *) (_bstr_t) db.m_pRecordset->Fields->GetItem ("Color")->Value;
I don't see why you need char *, _bstr_t should provide that for you automatically. A _bstr_t wraps a BSTR and a char *.
nss wrote:
strContent = (int*) (_bstr_t) db.m_pRecordset->Fields->GetItem ("Color")->Value;
Nope. Replace both casts with one to int. Of course your variable needs to be an int and not a char *. The reason it's a char * is that a char * is how strings are represented in C. A char is one character.
Christian
We're just observing the seasonal migration from VB to VC. Most of these birds will be killed by predators or will die of hunger. Only the best will survive - Tomasz Sowinski 29-07-2002 ( on the number of newbie posters in the VC forum )
|
|
|
|
|
The .vt value of the returned variant will tell you what type the returned field is. This will indicate how you treat the _variant_t data type.
The various data type can be found in the documentation of the VARIANT data type.
Here is a simple extract of how I tend to use the returned variant value from a recordset:
CString str = _T("");
_variant_t vtFld;
vtFld = pRecordset->Fields->GetItem(lpczFieldName)->Value;
switch(vtFld.vt)
{
case VT_BSTR:
str = vtFld.bstrVal;
break;
case VT_I4:
str = IntToStr(vtFld.iVal);
break;
case VT_DATE:
{
COleDateTime dt(vtFld);
szValue = dt.Format(_T("%Y-%m-%d %H:%M:%S"));
}
break;
case VT_EMPTY:
case VT_NULL:
break;
default:
szValue.Empty();
return FALSE;
}
Happy, Happy, Joy, Joy.
|
|
|
|
|
I have a CString array a[10], that I created with new. Now I want to copy this into another array
so do I create that with new as well, and do a loop like this?
CString *b = new CString [10];
for (int i =0, i < 10, i++)
{
b[i] = a[i];
}
Also for all the "new"s I make, I need to keep them around, so should I do the delete[] in th edestructor? What if I didnt. Is that bad?
Thanks,
ns
|
|
|
|
|
Yes, that's how you copy the array. Yes, you need to delete[] them all or you will leak memory. Overall, you'd be better to check out using std::vector for your array needs. I have a number of articles on CP regarding the STL, which is where vector lives.
Christian
We're just observing the seasonal migration from VB to VC. Most of these birds will be killed by predators or will die of hunger. Only the best will survive - Tomasz Sowinski 29-07-2002 ( on the number of newbie posters in the VC forum )
|
|
|
|
|
Vectors are great! I'm off to read about your views on STL! Thanks so much for the responses!
ns
|
|
|
|
|
You could also use CStringArray. It cleans up after itself.
/ravi
Let's put "civil" back into "civilization"
http://www.ravib.com
ravib@ravib.com
|
|
|
|
|
Christian already suggested STL vectors
One thing left: What's the difference between delete[] and delete.
C++ developer, even experienced ones, often tell that in C++ pointers and arrays are the same. However, this is wrong! C/C++ does syntactically not distinguish between pointers and arrays. Semantically pointers and arrays are quite different things! And this is the reason for two versions of operator delete:
CString a[] = new CString[ 10 ];
CString b[] = new CString[ 10 ];
delete a;
delete[] b;
Because arrays and pointers share the same syntax, both a and b in the above code could be interpreted as pointer or as array. However, as I wrote above, they are not sematically the same thing:
- The first delete statement (delete a) interprets <coda>a as a pointer. It therfore destroys the object (calls the destructor) to which the pointer refers - this is a[0]. Then the buffer itself is freed. The destructors of a[1] to a[9] are not called. Because CString objects manage their own string buffer and free in the destructor, these buffers are never freed for a[1] to a[9] and cause memory leaks.
- The second delete statement (delete[] b) interprets b as an array. It first calls the destructor for every single array element and then frees the buffer.
Technically the one and only difference is that if you use operatore delete[] the destructor of each array element is called, while operator delete calls only the destructor of the first element. Therfore for object types that do not have an user defined destructor, both are semantically equivalent:
TCHAR szBuffer = new [MAX_PATH];
...
delete szBuffer;
--
Daniel Lohmann
http://www.losoft.de
(Hey, this page is worth looking! You can find some free and handy NT tools there )
|
|
|
|
|
This is purely from a design viewpoint at the moment to help me understand OOP a little better - I don't want any code, just theory please.
Let's say we have four classes: Parent, Son, Daughter and Grandchild. Now if I was to model a typical local family it would look like this:
Parent
^ ^
/ \
Son Daughter
^ ^
\ /
[Grandchild<sup>n</sup>]
There can be multiple direct offspring of Parent based on this model, and each sibling pair can have more than one grandchild. Sometimes a sibling may choose to directly adopt a Grandchild without courting one of their brothers or sisters, but the siblings will never form a threesome (us country folk do have some standards you know!)
Now let's say Parent has some common attributes and methods, e.g. Age, GetAge and SetAge. How would this look from the Grandchild's perspective? I.e. how would a Grandchild determine it's age?
I'm not sure how to approach this one. 
This isn't technically related to C++, but I figured it would be the best forum given the choices.
One 18yrs male, red and white, good condition; daily servicing required. £500 collect ono.
|
|
|
|
|
Is your diagram an object inheritance chart or (as I suspect) is it meant to show the "is born to" relation? They are 2 very different things.
If it's an inheritance chart and the age methods are publicly defined in Parent, objects that inherit from it will also inherit the methods. So when you do:
grandChild.getAge() the method getAge() in Parent gets called.
If the method is defined virtual, descendant classes may override it. If it's defined pure virtual, they have to override (i.e. implement) it. In this case, Parent would be an abstract base class.
/ravi
Let's put "civil" back into "civilization"
http://www.ravib.com
ravib@ravib.com
|
|
|
|
|
Thanks Ravi.
Ravi Bhavnani wrote:
Is your diagram an object inheritance chart or (as I suspect) is it meant to show the "is born to" relation? They are 2 very different things.
It was *meant* to be an inheritance chart. Then again, I didn't pay much attention to that in class...
Ravi Bhavnani wrote:
If it's an inheritance chart and the age methods are publicly defined in Parent, objects that inherit from it will also inherit the methods. ... [etc]
That much I understand (wow!) but what is confusing me is say the Son and Daughter objects each provide overridden Get/SetAge methods, and the Parent object's method is called from within each to perform some common task. Now if I call Grandchild's GetAge member what gets used? Would it even work? If so, would the Parent's member get called twice?
My example of ages is getting a little confusing, so let me explain the real problem I am looking at:
In a game we have many CGameObject's:
GameObject
^ ^
/ \
Animatable Intelligent ... (there are more)
GameObject GameObject
^ ^
\ /
PlayerGameObject
GameObject provides a virtual method called Frame which is called each frame in the game to allow the object to perform any actions if required to. The GameObject.Frame method performs some basic "all objects require this" actions. The AnimatableGameObject.Frame method updates the animation status, etc. The IntelligentGameObject.Frame method evaluates the AI state of the object and calls its own methods as appropriate. The PlayerGameObject.Frame performs some calculations using user input and various other factors. Now I want PlayerGameObject.Frame to perform all of the tasks of all of the overriden (inclusing its own) and the original methods. Exactly how, if at all, would this work? Could I do something like:
PlayerGameObject::Frame()
{
AnimatableGameObject::Frame();
InteligentGameObject::Frame();
}
How would GameObject::Frame be called if both the AnimatableGameObject and InteligentGameObject overidden methods call it? Argh - my head!
One 18yrs male, red and white, good condition; daily servicing required. £500 collect ono.
|
|
|
|
|
David Wulff wrote:
Could I do something like:
Yes.
David Wulff wrote:
How would GameObject::Frame be called if both the AnimatableGameObject and InteligentGameObject overidden methods call it?
It would be called twice. That probably isn't what you want. So don't call it from both.
---
Shog9
If I could sleep forever, I could forget about everything...
|
|
|
|
|
Shog9 wrote:
It would be called twice. That probably isn't what you want. So don't call it from both.
Damn, thought so. The problem is that it must be called from both as their are other objects which in turn inherit from either AnimatableGameObject or InteligentGameObject. A thought has just struck me...
** don't all say "uh oh" at once now  **
If I add a parameter to each virtual function of the direct sibling objects (those like Son, Daughter, etc) like thus...
Frame([normal parameters...], bCallRootClass)
...then PlayerGameObject.Frame would look like this:
PlayerGameObject::Frame([normal parameters...], bCallRootClass)
{
AnimatableGameObject::Frame([normal parameters...], bCallRootClass);
InteligentGameObject::Frame([normal parameters...], bCallRootClass);
if (!bCallRootClass)
GameObject::Frame([normal parameters...], bCallRootClass);
}
And then do the same sort of thing in the AnimatableGameObject.Frame and InteligentGameObject.Frame methods.
That *should* work, no? The hierarchy would never go more than three deep, and it is only on the first sibling "stage" that mutliple inheritance would take place.
One 18yrs male, red and white, good condition; daily servicing required. £500 collect ono.
|
|
|
|
|
David Wulff wrote:
A thought has just struck me...
Ok, now you're *really* getting overly complex.
I wish i could remember, i just read a nice little technique for handling situations such as this... might even have been on CP. Can't recall 
But anyway, the gist of it is this:
- In the base class, have two methods. One,
DoFrameStuff() is not virtual, and implements the code you want shared between all derived classes. The other, Frame() is virtual, and just calls DoFrameStuff() (if you won't be instantiating (sp?) the base class, then just make it pure virtual). - In each derived class, implement a new version of
DoFrameStuff() that does only what the derived class adds, and doesn't call the base class method. Also implement Frame() as calling only DoFrameStuff() and BaseClass::DoFrameStuff(). - In the grandchild class, implement
Frame() as calling Child1::DoFrameStuff() Child2::DoFrameStuff() and BaseClass::DoFrameStuff() in order.
In this way, you have absolute control over the order in which the methods are called at each point. I admit, your system may be a bit more complex than this (my description assumes fairly simple interdependancies between each of the methods), but working from this basic structure it shouldn't be too difficult.
---
Shog9
If I could sleep forever, I could forget about everything...
|
|
|
|
|
Thanks, your idea looks good.
One 18yrs male, red and white, good condition; daily servicing required. £500 collect ono.
|
|
|
|
|
David James Wulff wrote:
Thanks, your idea looks good
<cough>godhelpus
I'm not a real reverend, I just play one on CP.
|
|
|
|
|
If I might be so bold, David, I think your entire paradigm here is flawed. From what little bit of information you provide, it would seem to me that the concept of a "GameObject" itself is the issue. What the heck sort of *thing* is a gameobject? IMHO, the object you need here is a Frame object. A "frame object" is a concrete concept which you could build a logical class structure around, a "game object" is not. That is the core of your problem.
A frame object would encapsulate frame related data which could be acted upon by such methods as:
UpdateAnimation();
UpdateAI();
etc...
The data contained within the frame object could relate to individual items of game logic which you might refer to as a "Game Object". But, I think if you reversed your thinking and made the game objects belong to the frame, rather than the frame object belonging to the game objects, you would benefit from a cleaner design.
I'm not a real reverend, I just play one on CP.
|
|
|
|
|
Reverend Stan wrote:
If I might be so bold, David
How dare you be so bold! I shall have you hung drawn and quartered for this! 
As I said, I am learning here - any input is welcome!
Reverend Stan wrote:
A "frame object" is a concrete concept which you could build a logical class structure around, a "game object" is not.
I understand what you are saying, I think. I just don't see how the Frame object would work withing the system.
A game object is an object in the game, be it a player or similar unit, a camera, a light, a helper object, etc. Each object when created will register it's interest in certain events (the example I have been using to-date is frame events). The events themselves are triggered and sent by the "Game" object (read: "CGame" not "CGameObject") which in turn takes care of the rendering, etc, etc.
What I am trying to do is to seperate all of the higher level game objects from the game itself, so as far as the game is conerned it only has a bunch of game objects to create, update and destroy. It never knows about animation, intelligence, states, etc, and it never knows if it is a player object or a camera - it just knows where it is and what it want's to know. It is by design that the "Game" object does not know anything about animation, inteligence, states, etc, either.
All this is supposed to make it easier to add new game objects using external scripts - well that was the idea anyway.
Have I totally missed something here?
One 18yrs male, red and white, good condition; daily servicing required. £500 collect ono.
|
|
|
|
|
First, remember that I have never designed a game, so I probably have no clue as to what I am saying. I am just thinking of the problem, to the limited extent I understand it, in terms of OO.
David Wulff wrote:
A game object is an object in the game, be it a player or similar unit, a camera, a light, a helper object, etc. Each object when created will register it's interest in certain events (the example I have been using to-date is frame events). The events themselves are triggered and sent by the "Game" object (read: "CGame" not "CGameObject") which in turn takes care of the rendering, etc, etc.
What I am trying to do is to seperate all of the higher level game objects from the game itself, so as far as the game is conerned it only has a bunch of game objects to create, update and destroy. It never knows about animation, intelligence, states, etc, and it never knows if it is a player object or a camera - it just knows where it is and what it want's to know. It is by design that the "Game" object does not know anything about animation, inteligence, states, etc, either.
That all sounds like a good design except that you are trying to get these objects to share state information. The concept of a Frame needs to be abstracted out of the concept of a game object. If the game objects need to update on a frame by frame basis, than collectively, they represent the state of the frame at any given moment, not vice versa. On a frame event all game objects need to be given the chance to update, but they are all trying to update the same frame, because, obviously, there is only one frame per state (a singleton perhaps?).
Think of a frame not as a state that the game objects share, but as an entity that they belong to. They are *its* state. The frame is itself a game object. The frame is a state management game object. All the other game objects belong to it. It can serve as a kind of factory class which generates the game objects it contains in a polymorphic fashion, thus acheiving the extensibility you desire.
To me, the game object itself should only ever be aware of one thing - the frame, and the frame manages the game's state from moment to moment. You could then swap derived frame types in and out of a game to achieve a very extensible design.
I'm not a real reverend, I just play one on CP.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
