|
Post by Ultima on Aug 26, 2006 18:36:26 GMT -5
patrickp: It loads Daemon Tools -- the Preferences has a place for specifying the DT install path. @gamesoul Master: Is there anything else you think I should/could change/add before I release?
|
|
|
Post by Gamesoul Master on Aug 26, 2006 18:42:49 GMT -5
Whatever caused this in the .ini file (I guess after the last time I closed the frontend, cuz I obviously never moved the file here):
Took me almost 5 minutes to figure out why it was starting, but it was nowhere to be found... until I maximized it on a hunch, saw the program, and then loaded the .ini thinking there might be a position setting in there.
|
|
|
Post by Ultima on Aug 26, 2006 18:44:17 GMT -5
I set it to open there by default, otherwise you see the window load at the center of the screen at default size before it gets moved/resized to its previous location/size. I'm not sure why it ever saved at that location for you though O.o
Edit: You probably exited the program before it had a chance to move itself to the previous location... I should probably make a check before the client exits.
Edit: Hm... mine shows -32768 instead of -32000 though when it happens to me =T
|
|
|
Post by Gamesoul Master on Aug 26, 2006 18:48:22 GMT -5
Why would you have it open at a location impossible to get to by default? Meh... not sure how it happened (it happened a second time, and then I couldn't replicate it). Why not just have the default at 0,0?
Another question: Is the "Enable Xenogears SPU hack" left on the list in case someone uses an older version of pSX?
Edit: Wait, you mean it opens there, reads its saved location and size from the .ini, and then sets itself to that? That would make sense, but why not just load the settings from the .ini first, and then start the GUI with those settings?
Edit 2: How about an option to disable sound (well, mute it if the "disable" still is broken)?
|
|
|
Post by Ultima on Aug 26, 2006 18:53:48 GMT -5
(About the first edit) I actually tried that a while ago, when I was still a greenhorn with AutoIt Script... didn't work out. I guess I'll have another crack at it. And yeah, the -S is there for older versions.
|
|
|
Post by Gamesoul Master on Aug 26, 2006 18:56:58 GMT -5
Just load the settings from the .ini (and set the return results to variables), and then use those variables as the parameters for activating the GUI (assuming it's like C++ in that loading the GUI requires the parameters to be set as passed values). I've done it that way before... is there something in AutoIt that inhibits that kind of usage?
|
|
|
Post by Ultima on Aug 26, 2006 19:03:58 GMT -5
Nah, I just remembered the problem... If I don't do the resizing offscreen, you see it actually resizing in front of you, which is annoying. Setting a window size when creating makes it the minimum size for the window, meaning attempts at resizing it to be smaller won't work. Besides that, when you set the size at window creation, the GUI widgets do not get stretched along with the window because the size specified at creation is the absolute minimum. Meh, I think it'll be less complicated to just leave it as I have it.
|
|
|
Post by Gamesoul Master on Aug 26, 2006 19:12:04 GMT -5
Yeah, I agree. I'm sure glad I never had to deal with that kind of problem in Java, else I definitely wouldn't have ever touched Java again. Not sure if it happens in C++, though (I'd have to test it out, but it doesn't really matter for now). Each language has its own quirks with GUI's, it seems.
Adding a check probably is the best thing you could do. However, might it be simpler to use an unsigned integer for the GUI position? Meh... I suppose that would require a check too, though, in addition to some extra exception-handling for negative values. Ok... you probably already know the best way to handle it, so I'll shut up now... -.-
Edit: Just realized that the exception-handling would be more difficult that I was originally thinking, as you would have to rewrite (well, copy/paste and modify) the unsigned integer class for the new exception-handling. At least I'm pretty sure you would. It's possible that you might be able to do that within your program, but I'm not sure with AutoIt. Either way... sounds like too much work my way (probably not the best way either, although I'd do it simply because I usually override or modify the classes I use anyway).
|
|
|
Post by Ultima on Aug 26, 2006 19:35:30 GMT -5
Hm, now that I think about it, I don't believe there's anything I can really do about it, as I have no way to tell if a coordinate is *actually* offscreen (multi-monitor setups can have negative window coordinates, AFAIK). Meh, I think I'll just be leaving it as is... not a big deal, and I can always FAQ it. Same goes for some warning dialog when selecting the hide log window option -- not going to bother, and will FAQ it. Up to the users.
|
|
|
Post by Gamesoul Master on Aug 26, 2006 19:39:59 GMT -5
But wouldn't the first monitor (the one on the left), take the starting value of 0,0 with the second monitor having higher positive values?
Besides, you can always just add a check for any value lower than -10000 or so (there's no way somebody could *put* a window at a negative X or Y coordinate that far away... no monitor supports anywhere near a high enough resolution to allow that). I really think at least *that* kind of check should be done, because that would be a simple check.
Something simple like that (that's the C++ method of doing it, but it's such a common and simple thing that I'm sure it's nearly, if not exactly, the same in AutoIt's custom language.
Edit: As an added thought, it's *always* a good idea to have checks like this in your code, in case somebody messes with the .ini unknowingly. I was actually rather surprised to find out you didn't have that kind of check already.
|
|
|
Post by Ultima on Aug 26, 2006 19:43:26 GMT -5
lol call me weird, but I don't really like hardcoding values, otherwise I would've added it already =T
Oh, and you can have a primary monitor on the right side, and another monitor to the left of it, which would make the coordinates for the second monitor negative.
|
|
|
Post by Gamesoul Master on Aug 26, 2006 19:47:16 GMT -5
Hardcoding a value is necessary in many forms of error-checking. How else could it be handled, without setting to their own constants and using those as bounds or default values (which is basically the same thing, but provides an easier way to change it later if needed)?
Edit: Interesting point on the double-monitor setup. I've never tried it before, so I'd have no clue about that kind of thing. The kind of code I mentioned still takes the possibility into consideration, though.
|
|
|
Post by Ultima on Aug 26, 2006 19:49:34 GMT -5
The thing is, I don't know if someone has a hundred monitors or something (hypothetical), and it's possible to have resolutions outside something I'd logically expect. Additionally, what if (like you say) someone plays with the INI file directly and sets the guiXpos and guiYpos both to -9999? Catches me off guard, and pSX Frontend wouldn't catch it if I hardcode the check to -10000. If AutoIt gave some kind of facility to check maximum and minimum coordinates and take multiple monitor setups into account, I'd pick that functionalilty up in a heartbeat and add the check. But alas, it doesn't, so I'm left wondering about these kinds of possibilities.
|
|
|
Post by Gamesoul Master on Aug 26, 2006 19:55:41 GMT -5
I know the error-handling can't be done in a completely robust manner (with your hypothetical situation), but nobody is going to have a resolution of anything higher than 3072 x 2304 (and I'm not even sure there's any video card in existance that could pull off *that* resolution), and so you could compensate accordingly. What about retrieving the current resolution and using those values as the max limits (negative and positive, of course)? If somebody really has more than two monitors in use, and has the primary as the furthest left or right, and closes the frontend too fast... then they can say something here when that time comes. Since it'll probably never happen, why not use the error-checking for the other 99.9% of us who *would* come across this problem? It's too unlikely to use as a reason to not include the error-handling.
Edit: I'm going to take a few minutes and see if there's some system file somewhere that physically lists the current resolution and other relevant settings. If I can find something like that, you'd have very little trouble using it, making the result well-worth it.
Edit 2: I found it, but it seems that the registry entry is specific to your graphics card. I found a file by the same name as the category, but once again that is specific to the graphics card. I'll search some more, because I believe there has to be some universal file or registry entry for the resolution setting that Windows would know how to use automatically (although maybe not... I'll soon find out).
Edit 3: Would you mind checking this location in your registry and tell me if the values you see there match your current resolution and bit-depth (if it exists, cuz I'm not sure what "iAlm" is, as it is nothing I have installed, nor an abbreviation for something installed, as far as I know): HKEY_CURRENT_CONFIG\System\CurrentControlSet\Services\iAlm\Device0
|
|
|
Post by Ultima on Aug 26, 2006 20:25:27 GMT -5
Nope, I've no such registry key. I tried combing the Registry already in hopes of finding something like that, but there doesn't seem to be anything particularly useful. I think I'm just not going to bother taking multiple monitors into account... for me, it's support all, or support nothing. I don't like having some partial or half-arsed implementation in place.
|
|