[Libreoffice-ux-advise] [Bug 41063] Saving/Autosaving (Save/Autosave) while in table causes view to jump to cursor position
https://bugs.documentfoundation.org/show_bug.cgi?id=41063 --- Comment #67 from Mike Kaganski --- The call stack that resets the view is the following: > swlo.dll!SwViewShell::IsViewLocked() Line 461 > at c:\lo\core\sw\inc\viewsh.hxx(461) > swlo.dll!SwViewShell::MakeVisible(const SwRect & rRect) Line 572 > at c:\lo\core\sw\source\core\view\viewsh.cxx(572) > swlo.dll!SwCursorShell::MakeSelVisible() Line 2828 > at c:\lo\core\sw\source\core\crsr\crsrsh.cxx(2828) > swlo.dll!SwFEShell::MakeSelVisible() Line 2584 > at c:\lo\core\sw\source\core\frmedt\feshview.cxx(2584) > swlo.dll!SwCursorShell::UpdateCursor(unsigned short eFlags, bool bIdleEnd) > Line 1844 > at c:\lo\core\sw\source\core\crsr\crsrsh.cxx(1844) > swlo.dll!SwCursorShell::EndAction(const bool bIdleEnd, const bool DoSetPosX) > Line 274 > at c:\lo\core\sw\source\core\crsr\crsrsh.cxx(274) > swlo.dll!SwCursorShell::CheckTableBoxContent(const SwPosition * pPos) Line 868 > at c:\lo\core\sw\source\core\crsr\trvltbl.cxx(868) > swlo.dll!SwCursorShell::EndAllTableBoxEdit() Line 923 > at c:\lo\core\sw\source\core\crsr\trvltbl.cxx(923) > swlo.dll!SwDocShell::SaveAs(SfxMedium & rMedium) Line 506 > at c:\lo\core\sw\source\uibase\app\docsh.cxx(506) > sfxlo.dll!SfxObjectShell::SaveAsOwnFormat(SfxMedium & rMedium) Line 3087 > at c:\lo\core\sfx2\source\doc\objstor.cxx(3087) > sfxlo.dll!SfxObjectShell::SaveTo_Impl(SfxMedium & rMedium, const SfxItemSet * > pSet) Line 1427 > at c:\lo\core\sfx2\source\doc\objstor.cxx(1427) > sfxlo.dll!SfxObjectShell::PreDoSaveAs_Impl(const rtl::OUString & rFileName, > const rtl::OUString & aFilterName, const SfxItemSet & rItemSet) Line 2847 > at c:\lo\core\sfx2\source\doc\objstor.cxx(2847) > sfxlo.dll!SfxObjectShell::CommonSaveAs_Impl(const INetURLObject & aURL, const > rtl::OUString & aFilterName, SfxItemSet & rItemSet) Line 2705 > at c:\lo\core\sfx2\source\doc\objstor.cxx(2705) > sfxlo.dll!SfxObjectShell::APISaveAs_Impl(const rtl::OUString & aFileName, > SfxItemSet & rItemSet) Line 307 > at c:\lo\core\sfx2\source\doc\objserv.cxx(307) > sfxlo.dll!SfxBaseModel::impl_store(const rtl::OUString & sURL, const > com::sun::star::uno::Sequence & > seqArguments, bool bSaveTo) Line 2970 > at c:\lo\core\sfx2\source\doc\sfxbasemodel.cxx(2970) > sfxlo.dll!SfxBaseModel::storeToRecoveryFile(const rtl::OUString & > i_TargetLocation, const > com::sun::star::uno::Sequence & > i_MediaDescriptor) Line 1666 > at c:\lo\core\sfx2\source\doc\sfxbasemodel.cxx(1666) > fwklo.dll!`anonymous namespace'::AutoRecovery::implts_saveOneDoc(const > rtl::OUString & sBackupPath, > `anonymous-namespace'::AutoRecovery::TDocumentInfo & rInfo, const > com::sun::star::uno::Reference & > xExternalProgress) Line 3061 > at c:\lo\core\framework\source\services\autorecovery.cxx(3061) > fwklo.dll!`anonymous namespace'::AutoRecovery::implts_saveDocs(bool > bAllowUserIdleLoop, bool bRemoveLockFiles, const > `anonymous-namespace'::DispatchParams * pParams) Line 2960 > at c:\lo\core\framework\source\services\autorecovery.cxx(2960) > fwklo.dll!`anonymous namespace'::AutoRecovery::implts_timerExpired(Timer * > __formal) Line 2310 > at c:\lo\core\framework\source\services\autorecovery.cxx(2310) > fwklo.dll!`anonymous > namespace'::AutoRecovery::LinkStubimplts_timerExpired(void * instance, Timer > * data) Line 2248 > at c:\lo\core\framework\source\services\autorecovery.cxx(2248) > vcllo.dll!Link::Call(Timer * data) Line 84 > at c:\lo\core\include\tools\link.hxx(84) > vcllo.dll!Timer::Invoke() Line 77 > at c:\lo\core\vcl\source\app\timer.cxx(77) > vcllo.dll!Scheduler::ProcessTaskScheduling() Line 448 > at c:\lo\core\vcl\source\app\scheduler.cxx(448) > vcllo.dll!Scheduler::CallbackTaskScheduling() Line 271 > at c:\lo\core\vcl\source\app\scheduler.cxx(271) > vcllo.dll!SalTimer::CallCallback() Line 56 > at c:\lo\core\vcl\inc\saltimer.hxx(56) > vcllo.dll!WinSalTimer::ImplHandleElapsedTimer() Line 158 > at c:\lo\core\vcl\win\app\saltimer.cxx(158) > vcllo.dll!WinSalTimer::ImplHandleTimerEvent(unsigned __int64 aWPARAM) Line 168 > at c:\lo\core\vcl\win\app\saltimer.cxx(168) > vcllo.dll!SalComWndProc(HWND__ * __formal, unsigned int nMsg, unsigned > __int64 wParam, __int64 lParam, bool & rDef) Line 642 > at c:\lo\core\vcl\win\app\salinst.cxx(642) > vcllo.dll!SalComWndProcW(HWND__ * hWnd, unsigned int nMsg, unsigned __int64 > wParam, __int64 lParam) Line 670 > at c:\lo\core\vcl\win\app\salinst.cxx(670) > user32.dll!UserCallWinProcCheckWow() > user32.dll!DispatchMessageWorker() > vcllo.dll!ImplSalDispatchMessage(const tagMSG * pMsg) Line 458 > at c:\lo\core\vcl\win\app\salinst.cxx(458) > vcllo.dll!ImplSalYield(bool bWait, bool bHandleAllCurrentEvents) Line 526 > at c:\lo\core\vcl\win\app\salinst.cxx(526) > vcllo.dll!WinSalInstance::DoYield(bool bWait, bool bHandleAllCurrentEvents) > Line 555 >
[Libreoffice-ux-advise] [Bug 118594] impossible to specify relative file link including URI's like file: or run:
https://bugs.documentfoundation.org/show_bug.cgi?id=118594 --- Comment #23 from muso --- > Unpack the file and run the included presentation. I hope it will be clearer > then. Thanks you for your file but it shows again the bug as I described it: - take your presentation and export it as PDF. result: the link is an absolute link. Move your PDF to another folder and you will get troubles. expected result: the link is a relative link - the link contains the URI "file:". For some file types one needs the URI "run:" to assure that the linked file is executed. So again, LO does not provide a way to create relative file links and one cannot use all defined URIs for links. (You might wonder why I insist on a PDF. In real life you never know on what PC you have to hold your presentation. Many PCs don't have LO installed. With the PDF you are always on the right side, also on Linux and Mac.) -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 101773] link frame style to paragraph style so applying paragraph style also applies frame style to current (or selected) paragraph
https://bugs.documentfoundation.org/show_bug.cgi?id=101773 --- Comment #7 from Regina Henschel --- (In reply to Regina Henschel from comment #6) > So it would be possible to include a reference to a paragraph style into a > frame style from point of file format. not "into a frame style" but "into a frame object". So linking paragraph style to frame style or the other way round is not possible on _style_ level. -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 101773] link frame style to paragraph style so applying paragraph style also applies frame style to current (or selected) paragraph
https://bugs.documentfoundation.org/show_bug.cgi?id=101773 --- Comment #6 from Regina Henschel --- I have to correct me. There is an attribute draw:text-style-name, which refers a paragraph-style. It can be used as attribute in a element and in most other graphic objects. But LibreOffice has not implemented the use of this attribute with common styles (=styles in UI). It uses it only for automatic style (=hard formatting in UI) of graphic objects. So it would be possible to include a reference to a paragraph style into a frame style from point of file format. -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 118594] impossible to specify relative file link including URI's like file: or run:
https://bugs.documentfoundation.org/show_bug.cgi?id=118594 --- Comment #22 from Regina Henschel --- Created attachment 143761 --> https://bugs.documentfoundation.org/attachment.cgi?id=143761=edit ExampleWithRelativeLink Unpack the file and run the included presentation. I hope it will be clearer then. -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 118594] impossible to specify relative file link including URI's like file: or run:
https://bugs.documentfoundation.org/show_bug.cgi?id=118594 --- Comment #21 from muso --- Created attachment 143757 --> https://bugs.documentfoundation.org/attachment.cgi?id=143757=edit Acrobat file execution dialog Also the execution dialog of Acrobat shows you that the created link is absolute. -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 118594] impossible to specify relative file link including URI's like file: or run:
https://bugs.documentfoundation.org/show_bug.cgi?id=118594 --- Comment #19 from muso --- Created attachment 143755 --> https://bugs.documentfoundation.org/attachment.cgi?id=143755=edit a test ODG file You can see that the file path is always an absolute path. -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 118594] impossible to specify relative file link including URI's like file: or run:
https://bugs.documentfoundation.org/show_bug.cgi?id=118594 --- Comment #18 from muso --- (In reply to Regina Henschel from comment #17) > You do not need "file:" or "run:" in case Windows has registered an > application to open .mno files. A simple hyperlink of type "Document" to the > file will work. Please try it. Thanks for your patience with me. However that is the bug. This doesn't work because: - the link is always absolute - the link contains then always the URI "file:" I need: - relative links to files to assure that they will be opened also on other PCs. - a possibility to decide which URI should be used and full access to all defined URIs. I attached now again an odg file to show you the problem. can't you see the problem? Also after exporting the odg to PDF you can see that the link created by LO is an absolute path. (I always use PDFs when presenting my stuff in front of audience because you never know on what PC you have to run your presentations.) -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 118594] impossible to specify relative file link including URI's like file: or run:
https://bugs.documentfoundation.org/show_bug.cgi?id=118594 --- Comment #17 from Regina Henschel --- You do not need "file:" or "run:" in case Windows has registered an application to open .mno files. A simple hyperlink of type "Document" to the file will work. Please try it. [BTW: The slideshow setting "Presentation always on top" has to be off. Otherwise you cannot work in that app.] -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 118594] impossible to specify relative file link including URI's like file: or run:
https://bugs.documentfoundation.org/show_bug.cgi?id=118594 --- Comment #16 from muso --- (In reply to Regina Henschel from comment #14) > I obviously wasn't clear enough. Seems that I was not clear enough. What I need but what LO doesn't allow me is to link to a file in general. For example I need to set a link to the file "test.mno" which is in the same folder than my .odg file. During hte presentation I need to click on that file link and the program that is connected in the Windows registry to open .mno files will open my test.mno file. To achieve this, I need in this form file:test.mno or run:test.mno The problem is that Lo doesn't offer me any method to set the URI "file." or "run:" -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 101773] link frame style to paragraph style so applying paragraph style also applies frame style to current (or selected) paragraph
https://bugs.documentfoundation.org/show_bug.cgi?id=101773 --- Comment #5 from Regina Henschel --- "Styles" are stored in a element in ODF. Such style belongs to a "family". In this context the families "graphic" and "paragraph" and "text" are relevant. A of family "paragraph" can have "paragraph-properties" and "text-properties" but no "graphic-properties". But a style of family "graphic" can have not only "graphic-properties" but it can have "paragraph-properties" and "text-properties" too. A element has no attribute to link to a style other than its parent in the inheritance chain. The properties are all directly contained in the element. You know this from paragraph styles. They have a tab "Font" where you can set text properties, but you cannot link to a character style. So what would be possible is, to extend the frame style with tabs for paragraph and text properties, which were used as default, if a property is not set in the actual paragraph of the inserted frame. = A frame has a structure Currently the paragraph style for the element is "Frame Contents" as default. We can make it user defined, but it can only be stored in user settings, not in the file. = The workflow contains the steps "convert an existing text into a frame" and the other way round "convert a frame into an ordinary text". That is independent of styles and has no effects on file format. Such enhancement of the UI would be possible. = @Zenaan: For your use case and a quick solution, I suggest you write a paragraph and a marginalia frame with all the needed style settings and then generate an AutoText from it. For the AutoText you need to select till the start of the paragraph, which is after the paragraph, to which the frame is anchored. -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 118831] Vertical alignment default should be top, not bottom
https://bugs.documentfoundation.org/show_bug.cgi?id=118831 --- Comment #17 from Kenneth Hanson --- (In reply to Daniel Collins from comment #16) > (In reply to Kenneth Hanson from comment #12) > > The case of column headers is a reasonable argument, thank you for that. Happy to help :) -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
