I'm looking to get the Hidden Classes in RPG Maker XP. i found the Window Class here (http://save-point.org/thread-2714.html) which has helped me extend the functionality of windows such as being able to have a custom margin size.
i've tried running the script here (http://forum.chaos-project.com/index.php?topic=8899.0) in an empty RPG Maker XP protect (i inserted it in a new script above main) but all it created was a bunch of .txt files with just a bunch of method names which are repeated in Public Methods but no code
one of the things i want to do is is look up how RPG Maker XP looks up fonts. i know that it looks them up in windows own directory but i want to know how it determines this for if the OS isn't on C:, why it doesn't error when no font is found and if there is an way to extend it to search other locations. but ofcause there are many other things i want to look up before i go asking every time
Hidden classes are exactly as they read: hidden. You don't have access to the underlying code-base for these classes. Any rewrites to these classes are the scripter's best interpretation of how the script works (usually) in pure Ruby. The Tilemap class, for example, is most likely largely written in C code since the amount of drawing it does is performance heavy.
btw Selwyn's Window class rewrite is not a perfect copy of Window. Blizzard's (https://forum.chaos-project.com/index.php/topic,15339.0.html) is nearly an exact replica where Viewports are not necessarily used correctly, but no one should be accessing a Window's viewport to begin with. Try using this windowskin and compare the two scripts
(https://i.imgur.com/g6lmz4P.png)
You should see the difference at the title screen, namely the cursor.
That script you linked from the ARC dev thread just grabs a list of the classes' methods and variables. Again, there's no actual source code because it's hidden. This was used mainly to get an idea of what they needed to implement their own version of the hidden classes.
For getting the fonts, it probably just uses the Windows' environment variables. For example, in Windows Explorer, typing %windir%\Fonts will bring you to the fonts folder. If the font isn't found, then RMXP just doesn't draw anything (I mean, there's nothing wrong with that). There isn't a way to manipulate the underlying code to look elsewhere for font files, so you have to use a script (https://forum.chaos-project.com/index.php/topic,13761.0.html) to get that done.
Hm, didn't I make viewports work with windows after all? Eh, doesn't matter. Nobody uses it anyway. xD
Yes, I made sure to emulate the original behavior as precisely as possible. So I suggest you use my rewrite instead of Selwyn's.
It does return something now if you try to access the window's viewport, yes. But the way the viewport is used is not how XP does it. I know that the way you implemented it was more so for convenience in positioning all the window's elements and not having to move all of them when--as an example--Window#x changes (as the top left corner of the window will always be at [0,0]; just only need to move the viewport).
IOW, your rewrite always creates a viewport the same size as the window. As such, the window is always in full view. You also cannot initialize the window to another viewport.
XP doesn't create a viewport unless explicitly initialized with one. And it behaves like any Sprite would (contents being clipped out if not contained fully in the viewport, etc.).
But default XP scripts never initializes any of the window sub-classes with a viewport. Hence, no one should be using the Window's viewport anyways. Only example I have seen so far is that online script whitespirits mentioned, where the author was drawing item description sprites to the Item Window's viewport, which were being clipped using XPA_Window (basically, there was no reason for the author to be initializing these sprites to the window's viewport).
Aha, I see. Yeah, since XP supported viewports, I assumed this is how they were supposed to work ie. how they do work since it made sense. It's cleaner and more obvious this way.