nvdaControllerClient distribution: move example_python.py and example_c.c in to the x86 subdirectory, and note in readme.html that  the libraries and headers are now separated in to x86 and x64 directories, and that the two example files are in x86.

nvdaHelper sconstruct: Fix description for logLevel. Lower (not higher) values are more verbose.

nvdaHelper SConscript build files: rearrange things so that now nvdaHelper dlls are built for both x86 and x64 architectures automatically. The TARGET_ARCH  variable is no longer supported on our scons commandline, however if scons can not set up a build environment for one of these architectures it still tries compiling for the other. I.e. people on an x86 system with no x64 cross-compiler can still build for their own system at least.
Specific changes:
*Move most of the main scons logic (all calls to sconscript files in subdirs and declaring of install and default targets etc) out of sconstruct and in to a new file: archBuild_sconscript.
*acrobatAccess and ia2 sconscripts: build files where the sconscript is, rather than back in the same directory as the original idl files. This allows for using a build directory separate from the source.
*sconstruct: set up environments for both x86 and x86_64, and call archBuild_sconscript under both environments, providing a specific build directory for each, meaning that all generated files for both architectures will be separated from each other. (build/x86 and build/x86_64).

nvdaHelper: replace all uses of the  c++ postfix incrementor operator with the prefix one, where possible. The only usage of the postfix operator should only be when earasing an element while incrementing its iterator at the same time. This change should provide some type of performance increase (even if it is only minimal). The postfix operator creates a temprary copy, increments the real one, and returns the temporary. The prefix operator simply increments the real one producing no temporary.

nvdaHelper sconstruct: Pass /win32 to midl when building for x86, as this is needed when using the x64 version of midl, which is used when configured by the Windows SDK setenv.cmd script on x64 systems.

Added a custom windowsSdk tool for SCons, which makes use of setenv.cmd provided with the Windows SDK, rather than using existing SCons logic to find versions of MSVC. This allows nvdaHelper to be built with Version 7.1 of the Windows SDK, which includes Microsoft Visual C++ 2010 (10.0). This Windows Sdk tool should work with any version of the Windows Sdk that ships with a setenv.cmd.

Remove some old source files not used anymore.

Merged nvdaHelperRemoteInjectionFix. This is a major rewrite to the structure and logic of nvdaHelperRemote in regards to how it injects and manages its in-process subsystems. This rewrite was needed to fix #399 (Destroying buffers in RPC rundown causes processes with loaded vbuf backends to crash), to properly fix crashes in applications when they exit (e.g. the NVDA installer) (due to the displayModel), and to fix performance issues introduced to previously try and fix the crashes on application exit. These changes may also help nvdaHelperRemote from getting stuck in processes that it shouldn't be in, or at least should no longer be in (when NVDA is no longer running).

Merged main

nvdaHelperRemote: replace a few assertions, MessageBox calls, and fprintf calls with LOG_ERROR/LOG_DEBUGWARNING calls. Also return early on a few errors. Use GetLastError in log calls a bit more where appropriate.

Syslistview32 controls: if there is no value retrieved from MSAA and the listview control is ownerdrawn use displayModel for retrieving the value

nvdaHelperRemote: fix some crashes on XP when exiting programs such as Windows CHM Viewer, and windbg etc. When programs exit, our inproc manager thread gets prematureally killed off by the OS with out allowing it to terminate all in-process subsystems. This means that  windows hooks, and API hooks can still possibly run while the process is exiting, however  nvdaHelperRemote's crt may have already been uninitialized, which means that  hooks accessing STL/CRT things may cause exceptions and heap corruption etc. So, detect when process detach is happening in dllmain due tu process terminate (rather than dll unloading) and specifically terminate windows hooks / API hooks.
Specific changes:
*No longer call apiHook_inProcess_initialize and apiHook_inProcess_terminate in inProcess_initialize and inProcess_terminate respectively.
*No longer call apiHook_enableHooks in inProcess_initialize.
*Take out the word inProcess from apiHook_inProcess_initialize and apiHook_inProcess_terminate.
*Call apiHook_initialize before inProcess_initialize, in the inproc manager thread.
*Call apiHook_enableHooks after inProcess_initialize in the inproc manager thread.
*Call apiHook_terminate before inProcess_terminate in the inproc manager thread.
*Split out the unregistration of current windows hooks, in the inproc manager thread, in to its own function: killRunningWindowsHooks, so it can be called from other places than just the inproc manager thread.
*dllmain (process detach): if the process is terminating (lpReserved is not NULL), and if the inproc manager thread has been killed off early (inprocMgrThreadHandle is not NULL), terminate hooks by calling apiHook_terminate and killRunningWindowsHooks.
*only call tlsFree if the dll is unloading from the process, rather than also if the process is terminating.

Merged main

nvdaHelperRemote: remove dllInjectionID and inprocInjectionID, and replace it with a completely different solution. dllInjectionID was problematic due to the fact that dll shared memory is shared across desktops, and therefore NVDA on one desktop could conflict with NVDA on another. The new solution is to use the inproc manager thread handle to detect when the thread is dying/ is dead, so that the injection_winEventCallback can start a new thread. Note that inprocMgrThreadHandle is now also set to NULL by the inproc manager thread itself, either just before it terminates, or if there is no existing NVDA process to wait on. This commit also moves the creation and deletion of needed RPC binding handles to dllmain (they used to be in the inproc manager thread). This change is to allow using log_* calls before/after the inproc manager thread.

nvdaHelperRemote: localize the injectionDone event to the current desktop. This is the first step in fixing  a bug where inproc manager threads would prematurely terminate if NVDA was started and terminated on a desktop separate to the first instance of NVDA. dllInjectionID needs to be re-thought to completely fix this as dll shared memory is shared across desktops.

Remove the function from winIPCUtils.cpp that generated the RPC endpoint address, and replace it with a function called generateDesktopSpecificNamespace, which only generates the "section.desktop" part of the string. This function can be used to help code localize any kind of IPC to the current desktop (e.g. a named event would include this string as part of its name). The rest of nvdaHelper has been changed to use this new function, and therefore also now generates the missing bits of the rpc endpoint address  in specific code. This change is specifically needed for a future commit to localize the injectionDone event to the current desktop.

speech.speakSpelling(): Move the handling of empty string/None below the handling of speechMode, isPaused, beenCanceled, etc. Fixes the issue where spelling blank text (e.g. NVDA+tab on an object with no name or holding backspace in some editable text controls) would keep saying blank without cancelling speech. Also fixes the issue where this would be spoken even when speech mode was set to off or beeps.

QT Client NVDAObject: A widget container may also contain a scrollbar in addition to the contained widget, so handle this case. This allows the machine list to be focused properly in VirtualBox in some cases where it wasn't before.

devenv app module: chooseNVDAObjectOverlayClasses(): Don't bother to catch NameError when removing DisplayModelEditableText, as this will never happen.

Add an app module for Microsoft Visual Studio 2005/2008 which provides support for the code editor. At least Visual Studio Standard is required; this does not work for the Express editions.

DynamicNVDAObjectType.__call__(): Fix comment.

nvdaHelper remote: inProcess hook callbacks: We need to copy the hook procs map before iterating over it because hook procs might be registered/unregistered while we are iterating, thus mutating the map and invalidating iterators. However, the map was previously being copied by iterating over it, which caused exactly the same problem. Therefore, instead of copying the hook procs to a list, assign them to another map. Hopefully, the copy constructor is an atomic map operation.

msn appModule: take out DisplayModelEditableText before inserting the MsnHistroy class. Allows the Histroy window in MSN messenger to be properly used again.

Do not use recently added debugging beeps if compiling as a release.

Hopefully fix the bug where NVDA could somtimes not successfully create a virtualBuffer when focusing on a document for the first time in a process, due to RPC not being setup in time.
Fixed by  providing inProcMgrThreadFunc with an event as an argument, which it sets to signaled once it has called inProcess_initialize. Injection_winEventCallback waits on both this event and the created thread, until one of them becomes signaled, or 1000 ms passes. This allows the active GUI thread to wait until all in-process initialization is complete.

Fix a crash that can occure when an API function is first hooked, and the hook function is executed but the real function pointer has not been set yet, due to the fact that apiHook_hookFunction has not yet returned.
Specific changes:
* apiHook_hookFunction no longer calls MH_EnableHook, only MH_CreateHook. This means that the hook will be setup, and the real function will be returned, but  all calls to the API function will not yet cause the hook to run.
* Added function apiHook_enableHooks, which iterates through all hook functions previously registered with apiHook_hookFunction, and calls MH_EnableHook for each. This actually hooks the functions, meaning that the hook functions may be actually called from this point on.
* inProcess_initialize: after initializing GDIHooks, call apiHook_enableHooks to actually cause hook functions to run if the hooked API functions are called.

Remove casts from calls to SetWinEventHook and SetWindowsHookEx as  they are not needed, and would hide callback function declaration errors.

Properly declare  callback functions used with CreateThread, rather than casting them and using a cdecl void function with no arguments. It really should be a DWORD stdcall function with one LPVOID argument. Although it is common to cast, apparently it can cause crashes on 64-bit.

No longer use moduleEnsurer in API hook functions. We now have other means of ensuring safety. Plus, this method seemed to add massive slow downs to NVDA in particular places.

nvdaHelperRemote's apiHook_inProcess_terminate: rather than logging errors (which most likely won't work because NVDA is already terminating or is dead), instead  just use some assertions. MH_DisableHook and MH_Uninitialize should really not ever fail, especially if MH_CREATEHOOK and MH_EnableHook worked ok.

Miranda-IM appmodule - properly fix support for clist classic so it won't use displayModel for retrieving the text. Thx jamie (fixes #674)

Miranda-IM appmodule: Worked around a problem where value of the classic contact list items is retrieved using displayModel (#674)
Added a hack preventing duplicate focus events for the bclist items. Basically this is a copy&n&paste from the utorrent appmodule.

Merged main

Fix for #399 (Destroying buffers in RPC rundown causes processes with loaded vbufBackends to crash).
Specific changes:
* Provide an acf file for the vbuf interface, that uses a strict_context_handle attribute on the acf definition of the interface. According to MSDN, strict_context_handle must be used for correct management of context handle rundowns when unregistering an interface. Strict_context_handle also  protects against a context handle returned from a method on one interface, from accidentally being used in a method on another interface.
* VBuf interface's distroyBuffer method in vbuf.idl: mark the buf parameter as being [in,out] as  the client provides it, but the server has to set it to NULL, so that the RPC runtime knows that the context handle is being destroied (and therefore not to call the context rundown once the client disappears). Previously this parameter had no direction marking at all.
* Simplify the code in remote/rpcsrv.cpp by getting rid of startServer and stopServer, and placing their respective code in rpcSrv_inProcess_initialize and rpcSrv_inProcess_terminate respectivly. After all, we are not actually starting any "server", even though rpc itself may do this as part of its implementation for auto-listen interfaces.
* Unregister RPC auto-listen interfaces with rpcServerUnregisterIfEx, as this is the only way to guarantee that all calls will complete, and all rundowns will be called to clean up remaining context handles, before this function returns. MSDN also makes it clear that this function should be used if a dll is unregistering auto-listen interfaces before unloading... which is exactly what we are doing. Note though that this function is apparently only supported on XP and higher, so this again suggests a breakage with compatibility on Windows 2000, if we still had any compatibility at all anyway.
* As we now use RPCServerUnregisterIfEx, also use RpcServerRegisterIfEx, rather than RpcServerRegisterIf2... more so just for simitry.
* Uncomment the body of the vbuf context handle rundown in vbufRemote.cpp, so that the rundown will now run, and correctly call vbufRemote_destroyBuffer, when NVDA disappears with out destroying the buffer itself.

IAccessible NVDAObject's children property: really fix typo (hopefully). Finding it hard to find a proper test case.

nvdaHelperRemote.h: add declarations for injection_initialize and injection_terminate. This allows remoteLoader64 to be compiled again.

IAccessible NVDAObject's children property:  fix typo. Thanks Lex.

IAccessible NVDAObject's next and previous properties: do not use correctAPIForRelation if the IAccessibleObject's are equal -- only changing child IDs there is no way the window can change. May provide a tiny speed improvement when using object navigation.

IAccessible NVDAObject's children property: go back to skipping Window root IAccessibles, as not doing this  added a major performance hit for getting dialog text (#668).  In principle the idea was fine, but this just showed up issues in functions such as getDialogText and speakDescendantObjects etc, which probably should be rethought before we consider changing children too much. Although this second rewrite of children goes back to the old way, it is still updated a bit, e.g. does proper API jumping at window boundaries, and of course is not all in between one large try except block. Hopefully this should take away the major lag when NVDA tires to read a dialog.

IAccessible NVDAObject: children and childCount properties: Handle the case where a value < 0 is returned for childCount, such as in defunct Mozilla dialogs. While this is probably a bug in Mozilla, it may happen elsewhere and it's not hard for us to handle it gracefully. This wasn't noticed previously because of the catch all for exceptions in the children property.

nvdaHelperRemote's apiHook code: as there is still the possibility that a hook function is currently running when all APIHooks are removed, a crash can occure if this running hook function then tries to call the real function. This is because this real function has now been cleaned up. To fix this:
* apiHook_hookFunction: make sure to freethe loaded library when returning because of errurs.
* add a g_hookedFunctions set, which will store the function pointers of all functiones currently hooked by apiHook.
* apiHook_hookFunction: add the function pointer to g_hookedFunctions once the function has been successfully hooked.
* apiHook_inProcess_terminate: rather than just calling MH_Uninitialize, and trusting that it will unhook and clean up, instead iterate through g_hookedFunctions calling MH_disableHook for each. This will stop the function being hooked (i.e. it will no longer be executed by the process), however it won't cleanup the data for the real function, which means that a hooked function can still safely execute the real function, at least until  MH_Uninitialize is then called.
* After unhooking all the functions, but before calling MH_Uninitialize, make this thread sleep for 250 ms. This should give other threads enough time to complete execution of any possible hook function, before all the data is cleaned up.

Note that  recent commits were necessary to allow  the usage of Sleep in apiHook_inProcess_terminate. Before those commits the sleep may have been performed in a GUI thread, or with in dllmain, which would cause freezes / more crashes.

Its probably possible now to remove the uage of moduleEnsurer in all hook functions, as the Sleep should take care of this. However this must be tested.

A major rewrite to nvdaHelperRemote to better handle unloading of the dll when its no longer needed by a process, to allow for fixing of more displayModel crashes, and to allow for future fixing of  the bug that does not allow us to clean up virtualBuffers if NVDA crashes. This change is also generally useful as it restructures things for better readability and understanding, and also provides a lot more protection against such things as NVDA crashing.
Specific changes are as follows:
* rename nvdaHelperRemote.cpp to inProcess.cpp as further changes will mean that it will only contain purely in-process code (specifically the management of the in-process subsystems).
* Add injection.cpp, which replaces all previous injection code in nvdaHelperRemote.cpp (now inProcess.cpp). the dllmain entry point function, and variables such as dllHandle and dllDirectory, have also been moved to injection.cpp. This means that inProcess.cpp now only contains code for managing the in-process subsystems (inProcess_initialize, inProcess_terminate, and the winEvent callback and Windows hook callbacks).
* add inProcess.h which provides declarations for inProcess_initialize, inProcess_terminate, and the winEvent and Windows hooks callback functions, though now with inProcess_ prepended to their names.
* nvdaHelper_initialize is now called injection_initialize (in injection.cpp).
*injection_initialize now creates a named event, and resets it to non-signaled before creating the out-of-process manager thread. This will be set to signaled when NVDA terminates nvdaHelper.
* nvdaHelper_terminate is now called injection_terminate (in injection.cpp).
* injection_terminate: after killing the outproc manager thread with wm_quit, it sets the named event created in injection_initialize to signaled. This is so that in-process code can detect when NVDA is terminating NVDAHelperRemote.
* the function for the outproc manager thread is now called outprocMgrThreadFunc, it used to be _nvdaHelper_localThreadFunc.  Other related variables have been renamed like that.
* The outproc manager thread no longer registers for all winEvents and Windows hooks, but instead only registers for focus/foreground winEvents, providing a new callback function (injection_winEventCallback). This winEvent registration is used purely for the purpose of getting nvdaHelperRemote.dll pulled in to appropriate processes. This now means that nvdaHelperRemote hopefully is not pulled in to  processes that are not user interactive.
* When the outproc manager thread first starts, it now increments a new dllInjectionID variable, which is stored in dll shared memory. This is so that in-process code can easily tell if NVDA has reinjected (i.e. injection_terminate and then injection_initialize yet the dll had not yet unloaded from the process), so that it knows it should start setting things up again via its injection winEvent hook, as opposed to just ignoring the event as its already set up.
* the injection winEvent callback (injection_winEventCallback) firstly ignores accidental out-of-process winEvents (threadID is not the current thread). It then sees if the dll has a new injection ID, and if so, starts a new inproc manager thread, who's job it is to initialize in-process subsystems, wait for nvdaHelper to terminate from NVDA, and then terminate all in-process subsystems. Finally, if it has just started the manager thread, it then forwards this particular winEvent to the real inproc winEvent callback so it doesn't miss it.
* The inproc manager thread grabs and releases a process-specific mutex while it runs, so that its impossible for more than one inproc manager thread to run at the same time.
* The inproc manager thread increases the ref count on nvdaHelperRemote.dll while it is running, so that it can be guaranteed that it will not unload during the lifetime of this thread.
* The inproc manager thread does the following tasks:
* Sets up some needed RPC binding handles (nvdaController and nvdaControllerInternal).
* Opens both NVDA's process and the event created in injection_initialize, so that it can later wait on them. If it can't open either of these things it does not bother doing much else.
* Registers for all winEvents in this process, using a new inprocWinEventCallback function.
* Initializes in-process subsystems with inProcess_initialize.
* Waits till either the event becomes signaled, or NVDA's process dies.
* Terminate all in-process subsystems with inProcess_terminate.
* Unregister winEvents for this process.
* Unregister any thread-specific Windows hooks that may have been registered during the running of the in-process code.
* Cleanup rpc binding handles.
* The inprocWinEventCallback (for all winEvents in this process) does the following:
* Ignores any event not for the current thread (accidental out-of-process winEvents).
* If this is the first winEvent for this thread (we make this decision by checking / updating a thread-local storage copy of dllInjectionID), GetMessage and CallWndProc hooks are registered for this thread. The callback functions used are the original Windows hook callback functions in inProcess.cpp (the ones that execute subsystem-registered windows hooks).
* Finally the real inProcess_winEventCallback (the one in inProcess.cpp that executes subsystem-registered winEvents) is called for this event.

Some notes for above:
* Access to dllInjectionID, the list of currently running Windows hooks, and the creation of the inproc manager thread, is all guarded by a lock called inprocThreadsLock.
* The only code now executed in dllmain is the allocation/freeing of thread-local storage, and the setting of dllHandle and dllDirectory. This means that in-process subsystems now are free to perform tasks like LoadLibrary/FreeLibrary, or Sleep etc with out worrying about whether or not their allowed to do it, due to being called from dllmain (which was previously happening).
* The initialization and termination of in-process subsystems is done from the inproc manager thread. Previously they may have been initialized in one GUI thread, and then terminated in another thread.
* NVDAHelperRemote is only injected in to a process if that process's GUI becomes active (moves to the foreground). Previously injection occured for any window message or winEvent in the given process, however proper initialization only happened when it was in the foreground. Thus, no visible change should be apparent to the user except for the fact that nvdaHelperRemote.dll hopefully won't be getting stuck in rather pointless processes like COM Sarigate, or Windows Update (when its GUI is not running) etc.

Although these changes fix a lot of important stuff, they do not yet directly fix the crashes in displayModel, nore do they fix RPC context rundown issues with virtualBuffers. However these changes do now make the fixing of these bugs much easier.

nvdaHelper.py: load nvdaHelperRemote.dll specifically with LoadLibraryEx, using an altered search path, so that nvdaHelperRemote.dll will be able to locate minHook.dll in lib. Note that Windows itself when loading nvdaHelperRemote for hooking does this already.

nvdaControllerInternal interface: add a getNVDAProcessID method. this will be needed in future by nvdaHelperRemote to help it open a handle to NVDA's process for synchronization purposes. The implementation of getNVDAProcessID is only in local's nvdaControllerInternal.c, and not forwarded to nvdaHelper.py as its  simple enough.

It is now clear that compiling minHook in to nvdaHelperRemote, and therefore letting both minHook and nvdaHelperRemote share the same multi-threaded crt, is dangerous because dead locks can occure when minHook freezes threads when hooking / unhooking functions. It seems that the multi-threaded crt contains some global locks to ensure exclusive access to some static members of STL containers and iterators.
When minHook then freezes all threads and then tries to access one of its hook stl vectors, a dead lock can occure if one of the frozen threads currently owns one of these static member locks. Therefore, rather than compiling minHook directly in to nvdaHelperRemote, compile it in to its own separate dll (with a static crt), so it is icelated from the rest of nvdaHelperRemote. Its annoying to have yet another copy of the CRT, but this is definitly necessary  to stop these kinds of dead locks.
 Specific changes:
* move minHook_sconscript out of remote and in to the root directory for NVDAHelper.
* Change minHook_sconscript to build and return a dll, rather than just c++ object files.
* Provide a minHook.def which does not seem to be included with the actual minHook distribution itself.
* Build/install minHook from NVDAHelper's main sconstruct file.
* nvdaHelperRemote now depends on the minHook dll.

nvdaHelperRemote: rename moduleHandle (the handle for nvdaHelperRemote.dll) to dllHandle for clarity -- also better matches the dllDirectory variable.

nvdaHelperRemote: rather than using __declspec(dllexport) to export functions in nvdaHelperRemote.h, instead provide nvdaHelperRemote.def. Using a .def file to export firstly provides one place that clearly lists all the exported functions, and secondly, not using dllexport in the header file means that other dlls/executables that include the header file will no longer accidentilly export these symbols themselves.

nvdaHelperRemote: add dllmain.h, which now contains extern declarations for moduleHandle and dllDirectory, which have been moved out of nvdaHelperRemote.h. This now means that nvdaHelperRemote.h will now only contain  things actually exported from nvdaHelperRemote.dll (no internal stuff).

UIA NVDAObject: Call initAutoSelectDetection() in the gainFocus event, rather than in the constructor. Querying for selection might not be valid while the object isn't focused. Also, the selection may change when the object gains focus.

UIA NVDAObject: __init__(): Ensure that this is only called once; just return for subsequent calls. This is necessary because __new__() can return a cached instance, but __init__() will still be called for it. We used to do this check, but it was removed at some point. Fixes broken text selection reporting in UIA editable text fields.

UIATextInfo: constructor: Collapse for POSITION_CARET, rather than just returning selection. Fixes reporting of the selection when review current character is used after selecting text.

default app module: Fix test_navigatorDisplayModelText script, which I broke when I merged devInfo.

Window NVDAObject: findOverlayClasses(): When checking whether to use DisplayModelEditableText, check for EditableText in all of the chosen overlay classes, not just the class chosen at the Window level. Fixes broken editable text support in Eclipse and probably elsewhere.

sysTreeView32.TreeViewItem NVDAObject: stateChange event: Fix typo when retrieving states from the speak object properties cache. Prevents incorrect speaking of item count when the item is already expanded but a state change is fired for some other state. Also some cosmetic fixes.

Maximise the Log Viewer and Python Console when activated.

Replace the very broken NVDA+f1 script with a new navigator object developer information command. This logs information about the current navigator object which is useful to developers and activates the log viewer so the information can be examined.

Merge main.

Work around the broken IAccessible implementation of MsoCommandBar windows, which are the toolbars in Microsoft Office XP-2003. Fixes crashes with NVDA+b and object navigation.
Fixes #616.

Add/improve docstrings for NVDAObject and NVDAObjectTextInfo.

core.main(): Initialise UIA before IAccessible. This is because otherwise, an IAccessible event can occur before UIAHandler is initialised, and IAccessibleHandler uses UIAHandler to determine whether an event is for a UIA window. This stops IAccessible from being used for a UIA window at startup; e.g. when landing in the items view in Windows Explorer.

IAccessible NVDAObject's childCount property:  should be 0 for all MSAA simple elements (IAccessibleChildID>0).

Cleanup to IAccessible NVDAObject's firstChild/lastChild/children logic.
Specific changes:
*IAccessible NVDAObject's firstChild/lastChild properties: If accNavigate can not give us a child, no longer try  calling super. Calling super is just inappropriate in many sercomstances as this object may not be the real client / only object for this window. Stops strange odities such as a random descendant window appearing as the firstChild of all leaf IAccessibles for a given window. E.g. Microsoft Office Ribbon controls always having a Font edit control as all their firstChilds. Also there is no need to call correctAPIForRelation if the IAccessible is identical for the parent and the child.
 *IAccessible NVDAObject's children property: Rewrite so that the whole thing is not in one large try except block (something we used to do a long long time ago), and so that it no longer tries to be smart about  giving back client IAccessibles instead of window root IAccessibles (next/previous/firstChild/lastChild stopped doing this a while ago, so children should as well).
*Due to the firstChild/lastChild change, add a ReBarWindow32Client IAccessible NVDAObject, which is the client for a ReBarWindow32 window, which overrides firstchild and lastChild to use IAccessible's super (i.e. Window). This is necessary as accNavigate is not implemented on these objects,  and  its IEnumVARIANT (children) have strange unavailable button IAccessibles between the child window root IAccessibles, which makes it rather hard for simple review to navigate through them.  This never used to be an issue due to firstChild/lastChild  calling super, which was wrong in all other sercomstances.
ReBarWindow32 windows are resizable toolbars or "cool bars" found so far mostly in Explorer, but could appear else where.

Note that these changes will cause NVDA+b to announce many more window objects when recursing through MSAA hyerarchis. However the nvda+b script really must be majorly rethought as it does not take simple review in to account, and its also rather MSAA-sentric.

Move the notification area (a.k.a. system tray) handling code into a specific overlay class in the explorer app module.

Added NVDAObjects.IAccessible.Titlebar which is used for standard MSAA titlebar objects.  This class  forces de description property to be empty (as MSAA's accDescription for these objects is rather annoying). And it hardcodes presentationType to layout. It was always layout, but it can be hardcoded here for performance. Indirectly the addition of this class now means that NVDA won't announce the text 'contains the name of the window and controls to minipulate it', when reading with the mouse at the very bottom edge of the screen... this seemed to be the titlebar of the taskbar.

winUser.setSystemScreenReaderFlag(): Use SPIF_UPDATEINIFILE as well as SPIF_SENDCHANGE. It seems that SPIF_SENDCHANGE has no effect otherwise. This ensures that WM_SETTINGCHANGE is broadcast, which is detected by applications such as Skype.

Window NVDAObject: displayText property: Gracefully handle the case where location is None.

MSHTML virtual buffer: Add missing import.

Merged fixLicensing branch which makes sure that all files in nvdaHelper have a clear copyright/license statement at the top. All of NVDA is GPL v2.0 accept for any files used in nvdaControllerClient, which is LGPL v2.1.

Removed license.txt from nvdaHelper as this was a left-over from nvVBufLib.

Make more nvdaHelper code GPL. The only things now in nvdaHelper that is not GPL is all client code, and any code it depends upon to comile (includes common/wnIPCUtils.cpp common/winIPCUtils.h, and the nvdaController acf/idl files.

Merge main

Added t2t user guide in portuguese and updated portuguese language file,
Updated finnish changes document,
Updated slovak language file, user guide and changes.

Update to latest AcrobatAccess IDL. We don't use any of the new functionality, but it is a cleaner IDL which, among other things, eliminates IPDDom.h. Note that people building nvdaHelper will need to update their IDL.

OffsetsTextInfo.find(): Err, we should use re.IGNORECASE if caseSensitive is False, not the other way around.

objidl: IMoniker.GetDisplayName(): Override to call CoTaskMemFree on the returned string, as documented in MSDN. Fixes a memory leak.

setup.py: Explicitly include objbase in the bundle, which isn't implicitly included.

First try at fixing crashes in programs when NVDA exits (e.g. the NVDA installer). It seems that some API hook functions are still in the middle of execution when nvdaHelperRemote.dll is being unloaded from a process. These changes try to ensure that the dll is not unloaded while in an API hook function.
Specific changes:
*make nvdaHelperRemote.cpp's moduleHandle variable (the handle for nvdaHelperRemote.dll) extern from nvdaHelperRemote.h so that it can be used by other source files in remote.
*Add new header file common/moduleEnsurer.h to nvdaHelper, which contains a class with all inline methods, that is used to ensure that a dll will not be loaded while an instance of the object exists, by passing that instance the module handle of the dll. It uses GetModuleHandleEx to hold the dll and FreeLibrary to  let go of it.
*All GDI/user32 API hook functions: first task for the function is to instanciate a ModuleEnsurer object, for the nvdaHelperRemote module handle. This ensures that nvdaHelperRemote will stay loaded until this instance goes out of scope (the function returns).

Ensure all nvdaHelper code is covered by the GNU GPL v2.0 license, which means all related files now have appropriate licensing/copyright comments at the top.

Ensure  all code in common, client, and the nvdaController interface, is all clearly licensed under the GNU LGPL v2.1.

AutoPropertyObject: Clarify documentation about caching to note how long the cache lasts.

queueHandler: Log errors when executing queued and generator functions using log.exception instead of log.error, as log.exception can then determine how it should be logged.

MSHTML virtual buffer: _setInitialCaretPos(): Gracefully handle exceptions when retrieving the URL from the document fails, as it sometimes can. There's nothing we can do, so just log and return.

OffsetsTextInfo: constructor: Fix documentation about when to call super.

explorer app module: Work around broken accNavigate on the language bar in the notification area, which was causing infinite traversal loops. Fixes infinite recursion when moving through top level windows with simple review. Should also fix infinite loops on the taskbar with speak foreground (NVDA+b).

textInfos.ofsets.OffsetsTextInfo find method:
 * actually handle caseSensitive argument
  * Use re.UNICODE flag for ignoreCase to work for non-english alphabets too. previously searching through non-english alphabets texts was always case sensitive, which I personally find quite anoying.

NVDAObject: presentationType property: Now that we have special handling for content generic clients (which sets presentationType to content), don't force any object with the focused state to be content. Eliminates a lot of annoying panes from simple review and focus ancestors.

Instead of always using display text for ListBox items, only do this if the ListBox is owner drawn and appropriate text hasn't been set. This means that we use MSAA wherever possible and therefore don't degrade the accessibility of ListBoxes which are actually already accessible.

A start on providing better documentation for the textInfos package.

Window NVDAObject's displayText property: handle the case where no text is returned from getWindowTextInRect.

UIA NVDAObject: kwargsFromSuper(): When retrieving the focus, we may get an object in a different window, so force recalculation of the window handle.

UIA NVDAObject: constructor: Always calculate UIAIsWindowElement based on cachedNativeWindowHandle instead of using the windowHandle argument if it was supplied. Previously, constructing a UIA NVDAObject with a window handle would always set UIAIsWindowElement to True, which may not have been correct.

Added support for owner-drawn staticText controls (NVDAObjects.IAccessible.StaticText). This class overrides name to use displayText if MSAA's accName is empty or whitespace. This class is used for windowClass of 'Static' with an MSAA role of STATICTEXT. Owner-drawn staticText is pretty rare, though one place this change is useful in is the chat log control of the Mirc IRC client.

nvdaHelper build instructions: Simplifications and clarifications.

changes: Additions and fixes.

Merged displayModel branch in to main! This merge provides main with the ability  of accessing many custom controls and owner-drawn menu items etc. The displayModel implementation, and NVDA's use of it, is now at a point where it seems rather stable, and certainly now is showing major advantages for users on a control by control basis. Support for such things as formatting (font, color etc), auto-announcement of new text, and cleaning up access to an application-wide flat review  can be considered in future, but what we have right now is certainly useful.

NVDAObjects.IAccessible.ContentGenericClient: shorten code to work out of truncation should occure.

Merged main

NVDAObjects.IAccessible.ContentGenericClient:
* change presentationType to be a class variable (no need for it to be a property).
* Force the role to unknown (making it much clearer to the user NVDA hardly knows anything about this control).
* Truncate its value (displayText) to 200 characters, placing an elipsis after if there is text removed. This is because the text could be arbitrarily large.

DisplayModelTextInfo._getPointFromOffset: raise LookupError if the offset is too large or there actually is no text.  DisplayModelTextInfo.NVDAObjectAtStart: catch LookupError when calling pointAtStart and return self.obj -- there is no descendant object at that (possibly invalid) point. This fixes exceptions when trying to sometimes use the navigator object after reviewing some text in a display model.

controlTypes: Change the "unknown object" role label to just "unknown", which is more concise and less scary for users.