UI error (version v83.0.7649.30836) #290
Comments
|
STA error report has been reproduced here; there's a new release in the works that I will push out on next saturday at the latest, any 'known bugs' of that one will be listed in its release notes. Got to keep the cycle as short as possible that way as I need you (and others) to test this stuff for me as there are several issues which ever so slightly different behaviour on my machine. 😓 Thank you for using Qiqqa and reporting back! The software release will be announced in all relevant issues, so you'll get to see it immediately when you have the default github account setup which is to receive email when a comment has been added to an issue you filed. |
…reads and out of the UI thread. - fixes the UI and other exceptions reported in jimmejardine#290, plus some of the stuff discovered in the logs from other submitters. - fixes a couple of slow-downs / lock-ups due to the code / thread re-org; discovered by analyzing the 'Threads' + CallStack views in the Visual Studio debugger. Done this in multiple tests on small and large / huge library systems (combined over 50K documents; which *does* cause out-of-memory issues still, unfortunately) - added `Unloaded` handlers for UI elements to ensure these remove/unlink PDFDocument references ASAP so that the .NET GC (Garbage Collector) can do its job soonest and best. NOTE: remember that the memory slowly fills up as you look at PDFs: the metadata and annotations (Inks, Annots, etc.) are loaded but *probably* never discarded. This is no worse than the old scheme where there was the "annotation cachee', which I removed a couple of commits earlier: with that one it was worse and *faster* towards out-of-mem. Anyway, a lot of work remains to be done to find out properly how and where we must cut to relieve the memory pressure: the memory dumps and diff analyses via Visual Studio means shows lots of detail, but no clear picture yet of what *really* matters. Next stage: cutting out Lucene and all 32-bit libraries, with known loss of UI/UX/functionality, just to see how this works out for memory pressure development during load and bulk processing of my huge test libraries.
|
Quick heads up: new release to try: https://github.com/GerHobbelt/qiqqa-open-source/releases/tag/v83.0.7655.37537 Please report anything you observe with the new release. Thanks! |
|
Quick heads up: hotfix release to try: https://github.com/GerHobbelt/qiqqa-open-source/releases/tag/v83.0.7656.6401 (which fixes known issue in previous release https://github.com/GerHobbelt/qiqqa-open-source/releases/tag/v83.0.7655.37537) Please report anything you observe with the new release. Thanks! |
|
Hi Ger. Well done, the UI error has not reappeared. v83.0.7656.6401 seems to work regarding my UI error. |
…I thread; the lib uses COM under the hood, which requires a working and accessible Windows message pipe, something which only the UI thread can provide. - littered the code with WPFDoEvents UI/not-UI assertions -- which caught the above scenario in a Dispose() for a page image render. And that was the hint the needed to progress a little further towards stibility: it was SORAX which caused a *lot* of the out-of-memory failures due to crazy COM/WPF/UI failures, even for smaller libraries under test. - fix bit of an odd crash in the Lucene flush/cleanup during shutdown, where Lucene kept busy with 'optimizing the index' while a quick application termination was happening in the background, resulting in lockup and then a crash. - this MAY be a fix for the reported "number of documents reported not matching reality": added update/refresh code to update the library list panel when PDF documents are added in the background via FolderWatcher or other means (async library loading). WARNING: this code is still incomplete/buggy! - most UI assertions have been covered now. Keeping them anyway as this is hairy stuff and should be tested more. Addresses (but is not guaranteed to fix) jimmejardine#290, jimmejardine#283, jimmejardine#281, jimmejardine#280, jimmejardine#243
|
Noted. I've been fiddling with the UI layout a bit; that 'widening' was not the intent. Next test release will have a document list that's more 'bunched up' to ensure you & I get to see a decent number of items on screen. 😄 Closing this issue. When there's trouble, please file a new issue. Thanks! |
Following error occured initially during startup of the app. Later when building a new Expedition and at the same time searching in the same library.
I'll send a log file to Ger.
20210113101158:System.InvalidOperationException: De aanroep-thread moet STA zijn, omdat dit voor veel UI-onderdelen vereist is.
bij System.Windows.Input.InputManager..ctor()
bij System.Windows.Input.InputManager.GetCurrentInputManagerImpl()
bij System.Windows.Input.KeyboardNavigation..ctor()
bij System.Windows.FrameworkElement.FrameworkServices..ctor()
bij System.Windows.FrameworkElement.EnsureFrameworkServices()
bij System.Windows.FrameworkElement..ctor()
bij System.Windows.Controls.Panel..ctor()
bij Qiqqa.Documents.PDF.PDFControls.Page.Annotation.PDFAnnotationLayer..ctor(PDFRendererControlStats pdf_renderer_control_stats, Int32 page)
bij Qiqqa.Documents.PDF.PDFControls.Page.PDFRendererPageControl.get_CanvasAnnotation()
bij Qiqqa.Documents.PDF.PDFControls.Page.PDFRendererPageControl.PopulateNeededLayers()
bij Qiqqa.Documents.PDF.PDFControls.Page.PDFRendererPageControl.<.ctor>b__33_0(Object o)
bij Utilities.Misc.SafeThreadPool.UserWorkItem(WaitCallback callback, Boolean skip_at_app_shutdown)
The text was updated successfully, but these errors were encountered: