Speaking of code, can anybody thing why IS might crash when I try and use this line of code "int myX = (int)isxwow.Me.Location.X;" inside .NET's OnPaint function? I've tried with and without frame locking. crash? or freeze Deadlock, yes. because i can tell you exactly why it would deadlock whether you explicitly frame lock or not, you are implicitly frame locking the UI thread is forced to sync with the game's main thread usually this isnt a problem. however, if you happen to enter any input... such as clicking, etc, then the input thread is waiting on the UI thread which is waiting on the main thread anyway instead of having the UI poll game data, push game data to the UI err that's usually a bad design usually what is a bad design, pushing data to the UI thread, or the ui thread polling? just don't put the update in the actual event-handler pushing data to the UI thread i would have to disagree the application shouldn't have to bother about what kind, or even if there is a user interface present it's clearly better to change the UI information when it needs to change, rather than have it continually polling Junior: All I'm trying to do is use System.Drawing to draw some graphics onto a radar, which unless I'm mistaken requires overriding OnPaint. just have the application expose whatever you may want to display through properties and let the UI, if any, poll those if you want to use a non-polling UI you should use a message that whatever ui you implement can catch the application still shouldn't be tightly linked to the UI he can do it however he wants, as long as the UI isnt relying on sync with the game's main thread or well, let's say the model shouldn't be tightly linked to the view or controller I must admit, I'm not following where the UI part comes in. The only UI stuff that I'm doing is using the drawing functions to draw shapes. The same app worked fine with a Listbox-based "radar". Are you saying that IS forces .NET apps running through it to synch their UIs with the game? no, i am not saying that YOU are forcing the UI to sync with the game with your line of code int myX = (int)isxwow.Me.Location.X; this locks the frame, which syncs with the game's main thread your UI is otherwise independent on the game's main thread if you want your UI to continue to function, i would recommend keeping it independent of the game's main thread ;) Thanks, I think I see what's going on now. BandicootBed : In you bot-class, save the coordinates on every update then expose those through a property, which simply gets it from the stored value So, anything which I've declared can be accessed without a problem ("stored value"), but if it goes through ISXWoW then it's framelocking, causing the deadlock? BandicootBed : calls to isxwow will framelock. every call you make will lock the frame are frame locks implicit now? they always have been they have been, always explicit frame locking has advantages beyond simply locking the frame Thanks, Junior. I'll modify my code based on what you and Lax have said. does that mean we don't have to call frame lock every time? Remember, I haven't messed with IS.NET is a long while. BlizzWishes : yes, but the framerate will probably drop you lock explicitly to ensure that code will execute in a single frame, which ensures that LavishScriptObjects (ones that are not LavishScriptPersistentObjects) are valid until reaching the unlock BlizzWishes : isxwow.me.location <- locks one time then unlocks, potentially advancing frame, if(isxwow.me.facing) return; <- locks again, and potentially advances, isxwow.me.face(pt.x,pt.y) <- lock again and potentially advances ok, I understand so just fetching the location, checking if you're facing, and if not start facing could take up 3 frames Yep, lock.. get all the info you need, unlock.. process based on info