Is it possible for a text box to honor markdown or formatting codes?

English
#1

I have a report that displays a field from a Base query in a text box. Is it possible to have the report honor markdown or formatting codes of any sort in the text? Or is there some other control that would do so – like a Windows “Rich Text Box”? I am not fussy: I would settle for html-type or surrounding underscores or anything at all like that.

I want the person who is entering the text into the database to be able to type “This is very important” or something like that and have “very” print in bold. (But only “very” – I know how to make the entire text box render in bold and that is not what I want.)

Thanks!
Charles

#2

Why not frames instead of text boxes? See second @ajlittoz’s comment.
Edit: So, the topic must be tagged with base instead of writer?

#3

No, unless you attach some macro to your text box. I assume you’re designing some kind of form where text entry makes sense.

I wonder if Base, the database interface component, equivalent to M$ Access, would be a better tool. Since Base is specialised for DB interaction, it is probably easier to do it than with Writer. And in case you need to build reports, there is a Report Generator which can output Writer and Calc documents.

#4

Let me explain the situation more. I have many years of coding experience but none of it database of any sort. I know SQL when I see it. I have taken over the “IT” for a small, local non-profit. The man who set up LibreOffice left for medical reasons. I am doing my best to bother him as little as possible. I am the only technology person involved. I really do not know what I am doing, but I am learning on the job.

There is a Base database consisting primarily of one table of clients. There is a client entry form that is used by the two people who enter and modify clients. There is one report program that prints a one-page “report” that is used by kitchen staff and drivers. It is driven by a query against that one key table.

It has been requested of me that the client entry people be able to “boldface” the “important stuff” in a general notes field. The notes print on the report. I am wondering if there would be a way for them to “mark up” certain information as bold and then have the report program honor that.

I am pretty comfortable now making changes to the report program but that is about the end of my comfort level. I am trying to take an approach of “first, do no harm” and I have not (yet?) touched the database schema.

So there is a context for the help I am looking for. I don’t see how to use a frame in a report generated from a table query. Am I missing something?

Thanks much for your patience and assistance.
Charles

#5

Since you’re interacting with a DB through a form or a simple report, frames are no help here. Frames make sense in Writer documents where they allow to create “secondary text flows” to complement the main text flow. The easiest example is side notes.

When you say you have “important stuff” in a general note, this makes me think that your general note has some kind of structure which is not backed by the present DB schema (consisting primarily of one table of clients). It looks like you have a text field where you enter information freely.

If this information should be split into “ordinary” and “important” facts, this calls for a list of unitary facts with a flag (importance). In other words, you need another TABLE for a one-to-many relation. The report generator can handle this situation. Since each fact is now separate, its flag can be used to highlight the fact any way you like.

My two-cents suggestion: group global “static” client data in your present TABLE and enter your facts in a separate TABLE, one entry per elementary fact, as a list for a one-to-many relation.

The structure is cleaner and more versatile.

#6

Although a text box has a “Text type” property with an option “Multi-line with formatting”, that option never worked for me. May be, I just don’t know how it is intended to work.

#7

@Villeroy this option may be related to handling of Enter key which would insert a line break instead of emitting a “submit signal”. The “formatting” is probably only the possibility to spread contents explicitly on several lines instead of relying on implicit line wrap. Just a guess.

#8

I assume your reports are generated Writer-files. As @ajlittoz I only see the option to use a macro, but IMHO there is no possibility to include the macro in the report.
.
It is possible to generate/open the report by macro, so the macro has a handle to the file. Until now I only used this to save in special location or send the file.
.
It should be possible to run search and replace before doing so, and I actually have a macro wich boldens all text in curly braces {text} while removing the braces to text as result.
Have to test, if I can combine this…
.
For the other way to input and save bold text, like @Villeroy I only know it is there. Maybe the (german) guide for Base has something on the topic…

#9

@ajlittoz Thanks. That’s good to know. Not relevant to my specific problem, but good to know. For my situation, we can enter < b > or * foo * with no problem but then the report program just displays them literally.

#10

And this is expected. Contents of a TABLE COLUMN is taken literally. If you want to add “semantics” on contents, you must handle it explicitly. It is “easy” (I should rather writer “customary”) to do it when you manage your DB through code (C++, Python, Django, …) but LO, mainly Writer, does not provide any feature for this, except perhaps macros but you’ll bump into the problem of triggering “adequately” the macro.

#11

Thanks all. Really appreciate your patience with a newbie to LibreOffice.

I suggested that we add a column to the database so we had two Notes columns: driver notes and kitchen notes. I could then print the former in a regular font and the latter in bold.

The powers that be have decided that the preferred solution it to tell the client entry people to always put the kitchen instructions first in the notes column and put them in all caps. Not quite the same as boldface, but close enough for nonprofit work, I guess.

#12

A modification of procedure is also a solution. Since it is not enforced by code, there still exists the possibility of human error. Somebody not following the rules can always enter non-conforming data. This will not be diagnosed and may break further processing.

If you have not the resources or knowledge to modify your existing “code”, this change of procedure is an acceptable workaround.

Impressum (Legal Info) | Datenschutzerklärung (Privacy Policy)   Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.