GuideMe (TeaseMe v2.0) - Current Build 0.4.4

[EroticDevelopment]

That reminds me. There is another issue I've noticed with hotkeys. If you are on page of a tease that has buttons with hotkeys and open the debug window to jump to another page (like while debugging or testing), if you start typing in the dropdown box to enter a page name, if that page name uses any of the hotkeys, the hotkeys trigger that button, even though technically the Guideme window no longer has focus, the debug window does. You have to jump to some safe page that doesn't have hotkeys, and whose name doesn't use any of the characters used as hotkeys on the active page.

I see what you mean - if you run GuideMe with java instead of javaw in the batch file so you get a command window, you can see all the listeners firing no matter what window you have open. There's some code that appears intended to prevent that from happening, but it's obviously not working and I don't really know why it's being done the way it is.

This one might be an EroticDevelopment problem.

Yeah, I can take a look at this. There's a lot of event listeners in GuideMe and it's hard to follow at times. I'm guessing some listeners just need to be removed/unbound at times or a variable introduced to return and not perform any actions.

[EroticDevelopment]

That reminds me. There is another issue I've noticed with hotkeys. If you are on page of a tease that has buttons with hotkeys and open the debug window to jump to another page (like while debugging or testing), if you start typing in the dropdown box to enter a page name, if that page name uses any of the hotkeys, the hotkeys trigger that button, even though technically the Guideme window no longer has focus, the debug window does. You have to jump to some safe page that doesn't have hotkeys, and whose name doesn't use any of the characters used as hotkeys on the active page.

I see what you mean - if you run GuideMe with java instead of javaw in the batch file so you get a command window, you can see all the listeners firing no matter what window you have open. There's some code that appears intended to prevent that from happening, but it's obviously not working and I don't really know why it's being done the way it is.

This one might be an EroticDevelopment problem.

It was done like that, because I hadn't done professional coding in ten years and was learning Java to get back into programming again. A lot of Guideme was written when my skills were very rusty, in a language I hadn't used before, so a lot of it was just the first thing I got to work

Hey, to echo what PlayfulGuy said it's great to see you stopping by and I hope all is going well.

Looking back on work you've done while new to a language is always interesting. I have my share of projects that I look back on and wonder why I ever did that and at my day-job role of merge-master would definitely not accept lol.

[PlayfulGuy]

This has been an issue in all versions of Guideme that I've used. I think it's always been like this, I just never got around to mentioning it since it really only pops up when you're trying to debug an issue with a tease that happens to use hotkeys.

I really don't know what to make of that, since it's definitely not happening in my copy of 4.4. Maybe something else about our installs is causing different behavior?

Well that'll teach me to check my facts before I speak! I just did a test in version 4.3, 4.4 and 4.5, and they are all working perfectly today, so you're absolutely right.

I actually moved to a new computer about a week ago and hadn't tried that since then, so it must have been something messed up on my old computer.

I'll make sure I test first next time.

PG

[RemiHiyama]

I looked through that one but didn't notice this was a part of that revert commit. I'll make sure this is put back in the next release.

Yeah, I'm not quite sure how that happened.

As for the rest of the timer stuff, I restored the branch for that on my fork, so I can submit a pull request with the good parts of the timer stuff at some point in the not-too-distant future.

Kind of not really? I'm building it on Windows (using mvn's "-P linux64" to set the profile) and then attaching the debugger remotely from my IDE on Windows. It works but isn't ideal. Since I'm running these VMs in VirtualBox it's not as bad. I can share the build folder to the VM and port-forward the debugging port.

Sounds like you're doing better than I am, I couldn't get host extensions to build so just getting development builds into the vm is a hassle. But I think I'd about reached the limits of my java skill as regarding the linux issues anyway.

Yep, that's a bug. If Remi hasn't resolved this one I'll take a look while I'm looking at some other hotkey issues mentioned above.

It looks to me like just replacing the places that have

Code: Select all

if (event.display.getActiveShell().getText().equals(shell.getText()))

with

Code: Select all

if (event.display.getActiveShell() == shell)

will fix this one. (And it should get rid of the issue with the Library window too, since it won't be trying to call getText on a disposed widget.)

[EroticDevelopment]

It looks to me like just replacing the places that have

Code: Select all

if (event.display.getActiveShell().getText().equals(shell.getText()))

with

Code: Select all

if (event.display.getActiveShell() == shell)

will fix this one. (And it should get rid of the issue with the Library window too, since it won't be trying to call getText on a disposed widget.)

I agree, but something makes me nervous... Checking equivalency against `shell` instead of `shell.getText()` seems easier and more intuitive, so it concerns me that Philo did it this way for a reason or to fix a different bug. When you check equivalency to an object, Java requires it to be the same instance / same heap address. The existing code is looking to see if it's an object of the same class rather than the same instance. I want to make sure that nuance isn't important here before changing it. If this ends up being important we can always just check that `shell` isn't null or disposed.

[RemiHiyama]

I agree, but something makes me nervous... Checking equivalency against `shell` instead of `shell.getText()` seems easier and more intuitive, so it concerns me that Philo did it this way for a reason or to fix a different bug.

More or less how I felt about it, actually.

When you check equivalency to an object, Java requires it to be the same instance / same heap address. The existing code is looking to see if it's an object of the same class rather than the same instance.

Not so; the current code is comparing the window titles. And, uh, it seems to be working now; I'm no longer able to replicate the original bug. Still, comparing the objects seems to be the more correct way to handle the issue, based on what I was able to find other people getting told to do. (See for instance https://stackoverflow.com/questions/376 ... -triggered )

(There are apparently circumstances where getActiveShell can return null, particularly on linux, but my impression is that "not run the hotkey handler" would be the desired behavior in cases anyway.)

I want to make sure that nuance isn't important here before changing it. If this ends up being important we can always just check that `shell` isn't null or disposed.

I don't know about important, but the LibraryShell issue is annoying. If you've opened and closed it repeatedly, you'll end up with multiple pages of error messages from the leftover listeners. We should probably be removing those...

[EroticDevelopment]

When you check equivalency to an object, Java requires it to be the same instance / same heap address. The existing code is looking to see if it's an object of the same class rather than the same instance.

Not so; the current code is comparing the window titles. And, uh, it seems to be working now; I'm no longer able to replicate the original bug. Still, comparing the objects seems to be the more correct way to handle the issue, based on what I was able to find other people getting told to do. (See for instance https://stackoverflow.com/questions/376 ... -triggered )

Reading this back I did a pretty terrible job of explaining what I meant here. You're correct, the current code is comparing window titles. While my statement about the existing code checking if they're the same class definitely doesn't hold for Java as a language, it does within the confines of GuideMe. Each shell class sets a unique title in the function that creates it, and that title is never changed. So, comparing shell titles should behave exactly the same as comparing class names for shells in GuideMe.

I went back and looked at Git history for this line, and it doesn't appear that it was intentionally changed to this for any particular reason. It was changed from something completely different when the Library window was added back in November of 2018 here. So, I think we're safe to change this. Even if you can't reproduce the bug right now, I can see how this could break and it's an easy adjustment.

[FCK88]

Hiya folks.

I've got a problem running the newest version of the GuideMe-software on my OS..

I've downloaded both the 32-bit and 64-bit Windows versions of the GuideMe 0.4.5-version and tried running them both, one at a time of course, but none of them would open up..

Why do I encounter this problem? Because with former version I've had NO problems running them whatsoever so a little help would be very much appreciated

FCK88

[RemiHiyama]

I've downloaded both the 32-bit and 64-bit Windows versions of the GuideMe 0.4.5-version and tried running them both, one at a time of course, but none of them would open up..

We're gonna need more to go on here.

Go into the logs directory and check guideme.log, are there any errors in there?

If there aren't, or the file isn't there, try opening up a command prompt and running start.bat from there and seeing if you see any error messages that way.

[FCK88]

I've downloaded both the 32-bit and 64-bit Windows versions of the GuideMe 0.4.5-version and tried running them both, one at a time of course, but none of them would open up..

We're gonna need more to go on here.

Go into the logs directory and check guideme.log, are there any errors in there?

If there aren't, or the file isn't there, try opening up a command prompt and running start.bat from there and seeing if you see any error messages that way.

I get a whole heap of errors in my guideme.log-file - if you want I can PM the log-file to you instead of posting them all in here cause there sure is a long list of errors I've encountered..

[ashikoki]

Hello, does this currently work with GuideMe? https://milovana.com/webteases/showtease.php?id=52907
I only get a black screen when trying to load the XML file.

Edit: I've tried another tease and it loaded and worked just fine.

[RemiHiyama]

I get a whole heap of errors in my guideme.log-file - if you want I can PM the log-file to you instead of posting them all in here cause there sure is a long list of errors I've encountered..

Usually just the first one or two things with the word "Exception" and the trace information is enough to work things out (not "error", since GuideMe logs a lot of things as errors that aren't actually errors), but if you want to send the entire log, that's fine. Just two things.

*It'll probably make things easier if you delete the existing guideme.log, try starting the program -once-, and then send the logfile that produces, both for size and clarity.
*The log file does contain some mildly private information - the login name you use on your computer, the GuideMe installation location, and the contents of the "path" environmental variable. You may want to remove those things (search and replace for the first two, and remove lines containing java.library.path for the last).

Part of why just posting the exception text is preferred is that the second part above is actually kind of a pain...

Hello, does this currently work with GuideMe? https://milovana.com/webteases/showtease.php?id=52907
I only get a black screen when trying to load the XML file.

Edit: I've tried another tease and it loaded and worked just fine.

Are you using PlayfulGuy's downloader? If so, you'd probably be better off posting in the thread for that rather than this one. If not... How are you running it then?

[FCK88]

I get a whole heap of errors in my guideme.log-file - if you want I can PM the log-file to you instead of posting them all in here cause there sure is a long list of errors I've encountered..

Usually just the first one or two things with the word "Exception" and the trace information is enough to work things out (not "error", since GuideMe logs a lot of things as errors that aren't actually errors), but if you want to send the entire log, that's fine. Just two things.

*It'll probably make things easier if you delete the existing guideme.log, try starting the program -once-, and then send the logfile that produces, both for size and clarity.
*The log file does contain some mildly private information - the login name you use on your computer, the GuideMe installation location, and the contents of the "path" environmental variable. You may want to remove those things (search and replace for the first two, and remove lines containing java.library.path for the last).

Part of why just posting the exception text is preferred is that the second part above is actually kind of a pain...

Hey again.

I've tried the first option you gave me which ended up giving me these lines in my log-file:

2022-02-15T02:49:35,495 TRACE App - Enter main
2022-02-15T02:49:35,573 ERROR App - GuideMe Version - 0.4.5
2022-02-15T02:49:35,573 DEBUG AppSettings - AppSettings userDir: *****
2022-02-15T02:49:35,573 DEBUG AppSettings - AppSettings userHome: *****
2022-02-15T02:49:35,573 DEBUG AppSettings - AppSettings userName: *****
2022-02-15T02:49:35,573 DEBUG AppSettings - AppSettings fileSeparator: \
2022-02-15T02:49:35,573 DEBUG AppSettings - AppSettings settingsLocation: data\settings.properties

Could you tell me where the problem is from these data or do I have to look for something else?

FCK88

[RemiHiyama]

Could you tell me where the problem is from these data or do I have to look for something else?

1. Find the first line that contains "Exception". (It'll be part of a larger word - something like "NullPointerException" or "IllegalArgumentException".)
2. Note that there'll be some indented lines below it that don't have date stamps that begin with "at".
3. Start copying a few lines before the line with "Exception" in it.
4. End copying a few lines after all the "at" lines and the date stamps starting up.

[FCK88]

Could you tell me where the problem is from these data or do I have to look for something else?

1. Find the first line that contains "Exception". (It'll be part of a larger word - something like "NullPointerException" or "IllegalArgumentException".)
2. Note that there'll be some indented lines below it that don't have date stamps that begin with "at".
3. Start copying a few lines before the line with "Exception" in it.
4. End copying a few lines after all the "at" lines and the date stamps starting up.

The problem is - what I posted in my earlier post is all I got from the guideme.log-file.. I don't have anything that says "Exception" or any of the other things you mention..