Description: In regard to Basic-IDE I'm missing a feature to export COLORIZED basic code in a WRITER document for furthermore usage. Therefore I wrote a little basic macro to do this job. The macro uses the basic function "replaceAll" and some "regular expressions" to colorize basic code the same way as to be seen when displayed by the Basic-IDE. It's just a workaround. If this workaround could be useful for the LO community feel free to use the macro as you like, e.g., as a workaround for the above mentioned missing feature. The better way surely would be to use the Basic-IDE display data while the basic code is displayed by the Basic-IDE, but this would be a big job to be realized and - in my opinion - not be done by LO developers next time because of other more important work to be done. Greetings Hans-Werner Actual Results: There's no Basic-IDE feature to export COLORIZED basic code in a WRITER document for furthermore usage. Expected Results: n/a Reproducible: Always User Profile Reset: No Additional Info: There should be a Basic-IDE feature to export COLORIZED basic code in a WRITER document for furthermore usage.
Created attachment 167433 [details] CodeColorizerBasic.bas
Created attachment 167434 [details] CodeColorizerBasic.odt
Created attachment 167435 [details] CodeColorizerBasic - ReferenceData.odt
Created attachment 167436 [details] CodeColorizerBasic - Info ENG.odt
Created attachment 167495 [details] CodeColorizerBasic - Info ENG.odt
*** Bug 138379 has been marked as a duplicate of this bug. ***
Created attachment 168747 [details] CodeColorizerBasic.bas Updated: CodeColorizerBasic.bas
Created attachment 168748 [details] CodeColorizerBasic.odt Updated CodeColorizerBasic.odt
Created attachment 168749 [details] CodeColorizerBasic - Info ENG.odt Updated CodeColorizerBasic - Info ENG.odt
Created attachment 168750 [details] CodeColorizerBasic - Info DEU.odt Updated CodeColorizerBasic - Info DEU.odt
Created attachment 168751 [details] CodeColorizerBasic - Info ENG.odt Updated CodeColorizerBasic - Info ENG.odt
Created attachment 168754 [details] CodeColorizerBasic - Info DEU.odt Updated CodeColorizerBasic - Info DEU.odt
What about all these extensions: https://extensions.libreoffice.org/en/extensions/show/71 https://extensions.libreoffice.org/en/extensions/show/code-highlighter https://extensions.libreoffice.org/en/extensions/show/coooder I'm not sure, if this should be a core feature.
Dear Hans-Werner, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping
OS: Windows 10 Home (21H2 - 19044.1741) LO: 7.2.7.2 (x64) + 7.3.3.2 (x64) (LibreOffice Community) T e s t D a t a Used for testing the macro basic code colorizing extensions: Attachment: "TestData.txt" TestData as to be seen in the LO Basic IDE: Attachment: "TestData - LO Basic IDE - ScreenPrint Part 1.png" Attachment: "TestData - LO Basic IDE - ScreenPrint Part 2.png" Attachment: "TestData - LO Basic IDE - ScreenPrint Part 3.png" Colors: Blue, Green, Red, Grey (only for comments) and Black (only for # @). E x t e n s i o n s [1] Code Highlighter https://extensions.libreoffice.org/en/extensions/show/code-highlighter Not working, only error message: Ein Scripting Framework Fehler trat während der Ausführung vom Python Skript vnd.sun.star.script:codehighlighter.oxt|python|highlight.py$highlight_qbasic_default?language=Python&location=user:uno_packages auf. Meldung: <class 'KeyError'>: 'codehighlighter.oxt' File "C:\Program Files\LibreOffice\program\pythonscript.py", line 1046, in getScript storageUri = self.provCtx.getStorageUrlFromPersistentUrl( File "C:\Program Files\LibreOffice\program\pythonscript.py", line 417, in getStorageUrlFromPersistentUrl package = self.mapPackageName2Path[ packageName ]" [2] coooder https://extensions.libreoffice.org/en/extensions/show/coooder No basic dialect found were basic macro code is colorized similar to the colorizing of the LO Basic IDE: Attachment: "TestData - coooder - basic4gl.odt" Attachment: "TestData - coooder - blitzbasic.odt" Attachment: "TestData - coooder - freebasic.odt" Attachment: "TestData - coooder - qbasic.odt" Attachment: "TestData - coooder - vb.odt" Attachment: "TestData - coooder - vbnet.odt" [3] Code Colorizer Formatter (Pitonyak) https://extensions.libreoffice.org/en/extensions/show/71 Very good colorizing, but not exactly like "LO Basic IDE" colorizing: + All special characters (outside strings) "( ) [ ] % ! $ : = - + &" are colorized "black", but should be colorized "dark blue". Only "@ #" should be colorized "black". + Variable names enclosed by square brackets are mixed colorized ("dark green" and "dark blue"), but should be colorized "dark green". + "Chr()", "InStr()" and "MsgBox()" are colorized "dark blue", but should be colorized "dark green". + "HEX" and "OCT" numbers are mixed colorized ("black" and "dark green") but should be colorized "red". + "REM", "REm", "Rem" and "rem" are colorized "dark blue", but should be colorized "grey". Attachment: "TestData - Code Colorizer Formatter.odt" [4] CodeColorizerBasic (no extension, basic macro) Uses for colorizing only regular expressions. No errors to be found. But this does not mean, that errors could never be found ... Attachment: "TestData - CodeColorizerBasic.odt" C o r e f e a t u r e ? [1] The Basic IDE is part of the core and therefore the Basic IDE printing feature [File]>[Print] is part of the core too. Isn't it ? [2] The Basic IDE printing feature seems to be a little bit old-fashioned, only black-and-white printing is possible contrary to the colorized basic macro code displayed by the Basic IDE. There's no "What You See Is What You Get" ... [3] Why not to replace the printing feature by an export-to-writer feature ? Colorizing basic macro code outside LO in the same way as is displayed by the Basic IDE is complex, difficult and error-prone. What's about to use directly or indirectly the already existing code colorizer of the Basic-IDE. For example, could it be possible to code some software that exports the displayed basic macro code in a writer document and replaces the SCREEN-color-tags by WRITER-color tags ? [4] The language of the descriptions of the (most) extensions is English. What's about LO users, that don't speak English ? If [3] could be realized, the language would be automatically the language of the LO version the user is using.
Created attachment 180588 [details] TestData
Created attachment 180589 [details] TestData - LO Basic IDE - ScreenPrint Part 1
Created attachment 180590 [details] TestData - LO Basic IDE - ScreenPrint Part 2
Created attachment 180591 [details] TestData - LO Basic IDE - ScreenPrint Part 3
Created attachment 180592 [details] TestData - coooder - basic4gl
Created attachment 180593 [details] TestData - coooder - blitzbasic
Created attachment 180594 [details] TestData - coooder - freebasic
Created attachment 180595 [details] TestData - coooder - qbasic
Created attachment 180596 [details] TestData - coooder - vb
Created attachment 180597 [details] TestData - coooder - vbnet
Created attachment 180598 [details] TestData - Code Colorizer Formatter
Created attachment 180599 [details] TestData - CodeColorizerBasic
(In reply to Hans-Werner from comment #15) > C o r e f e a t u r e ? > > [1] The Basic IDE is part of the core and therefore the Basic IDE printing > feature [File]>[Print] is part of the core too. Isn't it ? > > [2] The Basic IDE printing feature seems to be a little bit old-fashioned, > only black-and-white printing is possible contrary to the colorized basic > macro code displayed by the Basic IDE. There's no "What You See Is What You > Get" ... > > [3] Why not to replace the printing feature by an export-to-writer feature ? > Colorizing basic macro code outside LO in the same way as is displayed by > the Basic IDE is complex, difficult and error-prone. What's about to use > directly or indirectly the already existing code colorizer of the Basic-IDE. > For example, could it be possible to code some software that exports the > displayed basic macro code in a writer document and replaces the > SCREEN-color-tags by WRITER-color tags ? > > [4] The language of the descriptions of the (most) extensions is English. > What's about LO users, that don't speak English ? If [3] could be realized, > the language would be automatically the language of the LO version the user > is using. Let's ask UX team
Created attachment 180600 [details] CCB
Created attachment 180601 [details] CCB - User Manual ENG
Created attachment 180602 [details] CCB - User Manual DEU
(In reply to Hans-Werner from comment #0) > The better way surely would be to use the Basic-IDE display data while the > basic code is displayed by the Basic-IDE, but this would be a big job to be > realized and - in my opinion - not be done by LO developers next time > because of other more important work to be done. I fully agree- the desire for source code (actually only sbasic) as OLE object is clear. But there are more important things to do. And I appreciate features that are maintained in parallel - in other words extensions. Therefore I would upload the extension to our site and not implement this into core. Other opinions?
(In reply to Heiko Tietze from comment #32) > (In reply to Hans-Werner from comment #0) > > The better way surely would be to use the Basic-IDE display data while the > > basic code is displayed by the Basic-IDE, but this would be a big job to be > > realized and - in my opinion - not be done by LO developers next time > > because of other more important work to be done. > > I fully agree- the desire for source code (actually only sbasic) as OLE > object is clear. But there are more important things to do. And I appreciate > features that are maintained in parallel - in other words extensions. > Therefore I would upload the extension to our site and not implement this > into core. Other opinions? The "Let's ask UX team" questions are to be found in "Comment 28" (2022-06-06) and not in "Comment 0" (2020-11-20) ...
(In reply to Hans-Werner from comment #15) > [3] Code Colorizer Formatter (Pitonyak) > https://extensions.libreoffice.org/en/extensions/show/71 > Very good colorizing, but not exactly like "LO Basic IDE" colorizing: Code highlighting is a can of worms and better suited for a macro. If this one isn't working it might be good to fix the issues there. Andrew Pitonyak (CC) is an experienced and active macro developer. > C o r e f e a t u r e ? > [1] The Basic IDE is part of the core and therefore the Basic IDE printing > feature [File]>[Print] is part of the core too. Isn't it ? It's a module and likely using different code. > [2] The Basic IDE printing feature seems to be a little bit old-fashioned, > only black-and-white printing is possible contrary to the colorized basic > macro code displayed by the Basic IDE. There's no "What You See Is What You > Get" ... Agreed on the need to improve, if true (haven't tested myself). And if you can print/export it would be possible to insert the PDF. I suggest to check if we have a ticket about this aspect and file one otherwise. > [4] The language of the descriptions of the (most) extensions is English. > What's about LO users, that don't speak English ? If [3] could be realized, > the language would be automatically the language of the LO version the user > is using. Valid argument for a core feature but not a strong one. So in a nutshell no objection for a core implementation - if someone volunteers. Guess it's quite some effort for a limited benefit resp. some benefit for only a few users.
Created attachment 180810 [details] LO 7.3.4.2 (x64) - Basic IDE - ScreenPrint
(In reply to Heiko Tietze from comment #34) Many thanks for answering the questions [1],[2] and [4] of "Comment 28" :-)) But what's about the question [3] of "Comment 28" ? Code colorizing is already part of the core, because the basic macro code browsed by the "LO Basic IDE" (Integrated Development Environment) is colorized (Attachment: LO 7.3.4.2 (x64) - Basic IDE - ScreenPrint.png). Therefore ("Comment 28"): "[...] [3] Why not to replace the printing feature by an export-to-writer feature ? [...] What's about to use directly or indirectly the already existing code colorizer of the Basic-IDE. For example, could it be possible to code some software that exports the displayed basic macro code in a writer document and replaces the SCREEN-color-tags by WRITER-color tags ? [...]"
(In reply to Hans-Werner from comment #36) > But what's about the question [3] of "Comment 28" ? Writer document is preferably style-oriented text. You would have to create for each line a special paragraph style per code style (Basic, Python, Java...) plus numerous character styles to make parts in bold, italic, colored etc. Printing and exporting to PDF / bitmap formats is a more character-oriented procedure since you never reuse the content anywhere else. And as I commented before, the Basic colorization is likely not available at different modules. In other words, you don't write/modify code in Writer (nor you want to reuse the formatting) but want to share a static result - a screenshot. And again my disclaimer: the desire is clear and valuable from the UX POV (my expertise here). Volunteers who want to do the effort are very welcome. But I would not steer resources, if there was any, into it.
Copying to the clipboard using a rich text format as one of the formats would probably suffice and might be easier to implement. I have not attempted to read the IDE implementation code, so I could be wrong.
(In reply to Hans-Werner from comment #15) > E x t e n s i o n s > > [1] Code Highlighter > > https://extensions.libreoffice.org/en/extensions/show/code-highlighter > > Not working, only error message: > > Ein Scripting Framework Fehler trat während der Ausführung vom Python Skript > vnd.sun.star.script:codehighlighter.oxt|python|highlight. > py$highlight_qbasic_default?language=Python&location=user:uno_packages auf. > Meldung: <class 'KeyError'>: 'codehighlighter.oxt' > File "C:\Program Files\LibreOffice\program\pythonscript.py", line 1046, in > getScript > storageUri = self.provCtx.getStorageUrlFromPersistentUrl( > File "C:\Program Files\LibreOffice\program\pythonscript.py", line 417, in > getStorageUrlFromPersistentUrl > package = self.mapPackageName2Path[ packageName ]" Good news: Jean-Marc Zambon has picked up the maintenance of this extension. You can try it by downloading the "source code" in the releases, inside the archive you will find the .oxt extension file: https://github.com/jmzambon/libreoffice-code-highlighter/releases