[RM2K3] DYNRPG COMPILING ERROR

author=McBick
Does anyone know what is expected for this line of code?

RPG::WindowMenuSkill->winInfo->y = 120;
//Error: Expected unqualified-id before '->winInfo->y = 120' token

This is the code I am pointing to in the DynRPG Window.h;

class WindowMenuSkill : public Window {
		public:
			int heroId; //!< Database ID of the hero selected
			Window *winInfo; //!< The sub-window for the skill description
			Window *winHeroInfo; //!< The sub-window for the selected hero information
				int _unknown_84;
			DList<int> *skillSubsets; //!< Zero-based Array of skill subsets. Unsure about this though...
			bool isSkillSubset; //!< Is the selected skill a subset?
			//Window *winHeroMp; // ????

			void refreshSkills();
	};

I am guessing because WindowMenuSkill has the properties of class Window I have to point to the object in a different way than what I am currently using, but I have tried pointing to it several different ways, all of which results in the same error.

RPG::WindowMenuSkill is a class. A class is kind of like an advanced variable type, with multiple fields and methods belonging to it.
std::string is also a class, and you need to instantiate an object of the type std::string before you can use it. An exception to this is static methods and variables. This is why RPG::Image::create(); works, but RPG::Image->free() would not work. Still, remember that in DynRPG, you should normally not instantiated your own objects from the classes.

Instead vou need to consult this page:
http://www.rewking.com/dynrpg/group__game__objects.html
to see what instantiated objects you have to work with.

In your case, what you're trying to do should probably be something along the line of

Can't guarantee that it won't cause issues though, as I don't know if rm2k3 will like you messing with it's variables.
Also worth noting here is that "winSkill" is defined as a "RPG::Window" class, not a RPG::WindowMenuSkill class, meaning you should not really have access to the member variables specific to RPG::WindowMenuSkill.
In good C++ fashion, you would normally be able to get this access by
No idea if this would actually work here though, as these classes are not very conventional. (I expect this not to work, but this would be the general idea of how you would normally get access to those member variables).

related note: WindowMenuSkill is another class which "inherits" from the class Window. What this means is that WindowMenuSkill expands upon the class Window by adding extra member variables and methods, sometimes overwriting old methods from the original class with a new one. If you have an instance of WindowMenuSkill which has been instantiated as Window, and you only need members and methods from Window, there should be no problem. If you need access to the specifics of WindowMenuSkill, you need to start thinking along the paths described above.

author=McBick
I understand about instantiated rm2k3 objects, so I stay away from that. I am not sure what you mean by having an instance of WindowMenuSkill which has been instantiated as Window. As far as I can tell the objects in that class are static and can only be called, not instanced.

I tried using the dynamic cast operation, but get the error "not a polymorphic source". Ill continue to try using that type of method to see if I can get it to work.

Time for some terminology again.
An object is an instance of a class. Let's take string as an example again


If you look up the documentation of RPG::Window and RPG::WindowMenuSkill, you'll see that the keyword "static" does not appear anywhere. This means that nothing in these classes are static and cannot be called upon or used without an instance of that class.

RPG::WindowMenuSkill is a class, and not an object. You need to find an instance of the class to be able to use it (because of how DynRPG works).
This is why


The thing about DynRPG is that you are not allowed to create new instances of the classes mentioned, but you will have to use instances already made of these classes.
A quick way to discern these two are if the first letter following RPG:: is lower or uppercase. If it is lowercase, this means that this is an instance already made (by mapping it specifically to the existing memory in RPG Maker, which is the only way to create an instance for almost all DynRPG classes), and can be manipulated upon. If the first letter is uppercase, it means it's a class, and only static members (which are defined as such in the documentation) can be used, like RPG::Image::create(), which is labelled as a static public member in the documentation.
As you can see
RPG::battleData is an instance of RPG::BattleData, while RPG::WindowMenuSkill is simply a class definition (and the class has no static members, so you can't access anything in it without a pre-existing instance.

Again, you need to consult
http://www.rewking.com/dynrpg/group__game__objects.html
as to what instances already exist, since you can't create new instances yourself generally.

As for the dynamic cast operation, I figured that it probably wouldn't work (since DynRPG classes are anything but normal). My next best guess is that you'll have to use reinterpret cast and find the exact memory location of the window, and possibly toss in some dereference and address operators akin to what is done in the header files. I can't really say what would work here without experimentation as this is not the kind of code I'm particularly experienced with myself. Again, this should only be important if you actually need access to the specific variables members of RPG::WindowMenuSkill specifically. If all you want to do is mess with the y member, which is part of RPG::Window, you will not need this, and if you don't get access to it, is for different reasons, which has nothing to do with being able to cast the instance as the correct class (casting something, generally means to change the underlying type of the variable / object, and only works for cases where there is support for this. This will not help you directly, because all conventional wisdom will not work for DynRPG, but conceptually, you can learn more about this by reading about "polymorphism").

author=McBick
So that's why some classes are referred to with a lower case starting letter! This makes so much sense now!

When I mention instantiated objects, I meant specifically the ones the coder refers to and not the one that is declared in Dyn RPG, but now I have another question regarding this. In the header, the BattleData class has no static members. It is the same in the other header for the WindowMenuSkill class. Aside from the lower case letter needed for battleData the class object winSkill and winInfo are identical, though the latter inherits the Window class properties. So how and why are these two members so different to work with? Am I misunderstanding something here? There is a static reinterpret cast for BattleData, but does that change the class members to static?

It is not a requirement for the letter to be lowercase, but rather it's following a common naming convention. BattleData is the class and battleData is an instance of BattleData. On line 136 of BattleData.h you'll find

Now, I'm sure this line can be rather confusing as this is some rather advance stuff where you'd possibly run into some issues trying to google it. You'll be forgiven if you're not able to follow what I'm about to describe. Essentially, the class "RPG::BattleData" has been written in such a way, that the member variables fit perfectly on top of pre-existing memory as defined by the original RPG Maker software. "reinterpret_cast" here, dictates that you should take the address (0x4CDD38) and treat it as if it is an object of the class "RPG::BattleData".

In a sense, the original software has already defined the class RPG::BattleData, but this is normally not accessible because it's given as an already compiled binary, so this data has to be extracted from the memory through memory mapping (which is what is done here). This is why you shouldn't make another instance of RPG::BattleData either, as it's only existing once in the memory anyway, and it has already been mapped into the object RPG::battleData.

Again, RPG::battleData is an object, not a class. Because it is an object of the class, you can access all it's members. The fact that it's declared as static is of little interest here, as does not mean that anything inside the class has been converted to static.
I imagine you might be a little confused because you don't understand how C++ classes work, because you're learning from DynRPG, where most classes only have a single object (the global one accessible from DynRPG itself), but usually, classes are there to be treated as variable types which you can create as many as you like of, which is where the difference of a static member of a class kicks in, versus a normal member variable of the class, which belongs to the specific object itself.

All of this aside, I didn't read properly when I was skimming over the documentation, so I didn't see that "WindowMenuSkill" actually refers to the skill sub-window from the "menu". I thought it was the battle skill menu because I recall you've been working with that one so far, but that doesn't seem to be the case, so no wonder things seemed a bit weird.
The proper way of accessing it should be

probably while checking to make sure with an if statement that the skill menu is currently the active window.

This does render your question of "how winskill and wininfo" are different a bit moot, but it has to do with polymorphism. It is a bit involved to explain this, and it will probably just confuse you more than it will help you, so I'll leave this be for now.