Shawna, When you are in the IM window, you should be able to press shift-tab once to get to the message history. Once you do this, you should be in a browse mode like state where you can review the history with the arrow keys. If you don't hear anything when you use the arrow keys, you may need to turn browse mode on with control-shift-a. If you want to go back to the typing area, you will probably have to turn Window-Eyes browse mode off by pressing control-shift-a again, then press tab once to get back to the edit box.
I'm trying to think of ways to make the issue of turning browse mode on and off a more automatic process for future versions of the script. Some ideas I've come up with are to bypass the AIM native conversation history window and using a dialog to display the history, or perhaps just hotkeys to review the history. -Cory -----Original Message----- From: shawna [mailto:[email protected]] Sent: Friday, June 04, 2010 10:27 AM To: [email protected] Subject: question about the AOL scripts I downloaded and installed the scripts for AOL instant messenger a few days ago. Window-eyes reads everything like it should, but I've noticed that when you are in a conversation there is no way to move between the tyoing window and the conversation history. Can somebody tell me if there is any hotkey that I can use to move between the typing window and the conversation history? -------------------------------------------------- From: "Ron Parker" <[email protected]> Sent: Friday, June 04, 2010 10:20 To: <[email protected]> Subject: Re: atomic operations in VBScript > On 5/29/2010 1:14 PM, Chip Orange wrote: >> Oh, for instance, get some info out of a particular dictionary object. I >> test if it exists, and then when I go to get info out of it, I get an >> error >> because it no longer exists, because some other event handler has removed >> it >> (as it should); but these types of conflicts where objects are created >> and >> modified and deleted by more than one thread really could use some atomic >> control, and I was wondering if anyone had already solved this issue. >> >> > > Are you talking about two event handlers in the same script? If so, they > don't run in separate threads. ActiveScript scripts only have one thread. > Normally, everything you do would be atomic. However, since the Dictionary > object lives in a different process (in Vista and above, anyway) the call > to access it might let the second event handler call sneak in while the > first one is waiting for a reply from the other process. > > If you used a local boolean variable to control access, changes to that > variable's state should be sufficiently atomic. However, because the > problem isn't actually multiple threads but re-entrancy on the same > thread, you have to figure out what you'll do in that other event handler > if it can't get acquire a lock on the Dictionary object. It can't just > block, because that'll cause a deadlock. That, unfortunately, is not an > easy problem to solve. One thing you could do is queue a function that'll > try again later, but then you run the risk that some third handler might > fire and try to use the object after it should have been deleted by the > second, and so on. Good luck with that part of it; this is the stuff that > keeps programmers up nights. > > There is a related topic having to do with multiple scripts trying to > access the same shared object. In that case, you really are talking about > synchronizing multiple threads, but you're also presumably talking about > the possibility of having two scripts from two or even three different > authors involved. When that's likely, the synchronization should be part > of the shared object's public interface. If the shared object is > implemented by an ActiveScript script, it will also run in a single > thread, which means (again) that you can't make it block on failure, so in > this case the calling script needs to block (or handle the failure to > acquire a lock some other way, possibly by rescheduling the attempt. That > depends on what your caller wants to do and whether it itself is in a > situation that can't block, such as a keyboard event handler.) So, in > addition to whatever other properties and methods your shared object might > have, it would also have methods like "AttemptLock" and "Unlock." In the > simplest case, there's no enforcement of any of this. An unscrupulous > script could call Unlock without first succeeding at AttemptLock, or could > just skip calling the lock functions at all, and that would break things. > But as long as all of the object's clients adhere to the contract, it'd > work. (This is just like critical sections in Win32 API programming: > acquiring one is optional, and if even one thread fails to do so before > working with a nominally protected resource, the whole house of cards > falls down.) >
