The arrows are in a permanently disabled state despite me having added several columns, I started with 3 then added another 3 later but I can only access the width for 4 columns in the dialogue, the other 2 are hidden out of view and I cannot access them. I’m on manjaro cinnamon if that’s of any relevance.
Also I would prefer a normal scrollbar like you get in a browser than a couple of buttons that don’t feel right, please provide the option to use scrollbars instead of plain arrow buttons in dialogues.
I’m on manjaro, it’s gonna be the latest non-development install available anywhere, but in case you’re still gonna be picky and want currently irrelevant info, here’s what LO put in my clipboard when I clicked the copy button (which does NOT feel right, would prefer to be able to select the text & copy manually):
Version: 7.2.7.2 / LibreOffice Community
Build ID: 20(Build:2)
CPU threads: 16; OS: Linux 5.18; UI render: default; VCL: gtk3
Locale: en-GB (en_GB.UTF-8); UI: en-US
7.2.7-5
Calc: threaded
In addition, the dialog in the screenshot hides the table. We can’t tell if there are just 4 columns as advertised in the dialog or more. The best thing you can do is attach a sample file to your question.
Just a guess: it looks like you have used a so-called table style. They are not reliable if you need to make adjustment to your table. They work fine if you can build your table at first trial in a single shot.
Also View>Formatting Marks was not enabled, which is a strict minimum with screenshots.
@ajlittoz
The problem IS the interface, perhaps some bit of code checking for the extra columns is not quite doing it’s job right, either way you don’t need a file, you can replicate the actions I posted to see if the issue lies there, in doing so you get your test file.
Edit: Having just tried making a table with 6 columns from the outset I can see it had nothing to do with the flow of my actions and must be something to do with how LO, or maybe LW specifically, identifying the number of columns or reporting to the dialogue the number of columns or simply the dialogue’s own column count check, I don’t imagine you’re using multiple dialogues for table properties so I think it’s safe to assume it’s only one of those 3 scenarios to check the code in.
Edit 2: In case any devs paying attention cared about my suggestion on where to start looking, I would start at the dialogue itself, check the conditions, if they’re okay then I would trace back where it’s getting it’s information until I reach the code checking what is and is not a column to count, pretty sure would find the bug or missing implementation (whichever it is) before reaching that point.
Absolutely no. My computer has a highly-tuned configuration, not the same as yours (e.g. you have GTK+ widget library – you may consider this irrelevant but it isn’t – and I use Qt). I have no problem with tables. First step towards cure is to rule out issues like feature misuse. They are usually not intentional and result from different skill levels between users.
So, either the problem is in some subtle setting in your document or it is a bug (and again should be split between LO, widget interface and OS).
I can’t diagnose anything without looking carefully to your table. Of course, you’re free to refuse help. But, in this case, you’re on your own to fix the issue.
It’s NOT a setting, The only thing I changed of my settings was fonts & theme, nether of which would effect this, plus it was a brand new document so no chance of there even being a setting that I would have changed for the document specifically besides the fonts, in this case I switched some to Liberation Mono but in general I go for either Deja Vu or Google Noto fonts, I seriously doubt LO has an issue with either of those that would effect column counts, likewise I seriously doubt a change in theme &/or icons would effect column count. Please stop belittling me, I’m a programmer and know well enough that some configurations can cause problems, if I thought for a moment something of my configuration would be effecting it I would’ve already mentioned it in my 1st post.
if you think this is a bug, the place to report bugs is bugzilla. This is a ask-site where other users of LibreOffice answer questions. Often solves problems, but most of us don’t read the source of LO.
Some hints: LO-developers do NOT provide all versions available. Linux maintainers select/omit code to be compiled. So not everybody will be familiar with “latest lo on Manjaro”. (I was surprised you named a 7.2 as newest available version, while I’m using 7.3.5 and 7.4.1 is available pre-released.)
Personally I don’t think it is “counting the columns” causing your bug because this should show on all environments, not only with cinnamon, but maybe you are right and lo contains some code to count columns different on cinnamon.
I use word setting with a very broad meaning for “custom usage of any feature” failing for a better word. This covers the case of building a table which is not a “simple” object. Moreover, I suspect you did it with “table styles” which are in fact a collection of macros causing many things to happen behind the scene. And many misbehaviours in the past could be tracked to them.
Wrong! Dark themes are known to have difficult coexistence with LO. Does the some problem happen with a non-dark theme?
Although you claim to be a programmer, you have not explored your context to eliminate the possible consequences of your changes. With computers, you can never tell “such event is impossible”. So, even the “impossible” should be test, however illogical it may be.
This is my last offer: either you attach a sample file or I quit.
Edit: That PS of yours about the paragraphs, if you take a look at the content you’ll see they are woefully inadequate for what I need, I do plan to print this lot later so using a database app is not appropriate either, btw it’s data I’m pulling from hacking my game in epsxe, The values on the left also change when I change locations by walking so until I identify the purpose of them they’re being stored in the doc also so I have them if I need them.
@Wanderer
Only just realised there were further comments and that they were hidden, “latest available” release is still correct to say, since it is latest available on the manjaro repos, but I’ll concede your point that it’s not the latest LO everywhere, I didn’t realise it was the case, either way it should be expected that manjaro, arch based distro, would have a recent enough edition that, assuming this issue hasn’t been raised elsewhere that I I haven’t seen yet, one can assume it’s not a versioning issue. As for the bugzilla, I didn’t know it existed, I just followed a help link from somewhere, don’t remember if it was the package manager, an LO dialogue or a DuckDuckGo search though. Thank you for the link, as soon as I’m done looking at the remaining comments I’ll go take a look.
@ajlittoz
I only inserted the one table then use the context dialogue to add the columns after, I later tried an additional table insert after the table (with a space in between to stop it joining) with 6 columns from the get go, the issue still cropped up so I’m certain it has nothing to do with styles.
Edit: Since it appears admin have not gone and manually disabled the limit on my account nor can I put multiple images in 1 comment so I’ll just have to add my reply in here: @ajlittoz
Nope, 0 effect besides harming my eyes:
Just tried to print screen the option I used twice but for whatever reason it appears to be blocked or going to the wrong place, anyways I clicked on the “Table” menu from the toolbar and clicked “Insert Table…” which is directly beneath it in the list that shows up.
That would still only effect UI colour contrasts, nothing to do with the document that LO draws itself, nor the sizes & options that LO decides itself, now if I had been using a custom control style with say animated flames for it’s boundaries box, then yes I could see that conceivably confusing LO enough to get things wrong, when it’s just a slight adjustment of window & control boundaries it would only shift the controls slightly, not effect if they’re enabled or not.
Since you clearly can’t be convinced your barking up the completely wrong tree in another field altogether from the problem tree, here’s the file I was working with:
Edit: Tried to put this in another comment but apparantly I’m only allowed 7 comments in 1 day, seems silly to me but whatever. For reference, these are my theme settings, I don’t use adwaita icons because they look ugly in places so I defaulted to another:
Right-click on table, then, Table Properties works fine here. I can navigate to any column in the dialog.
Interacting with dark theme is sometimes very difficult. In your case, you must click on an “arrow-button”. This button may be badly generated and remain in disabled state. There are several questions on this site about faulty interaction between LO and dark theme widgets. So, check with a non-dark theme.
Here LO 7.3.4.2, Fedora 36, KDE Plasma desktop (Qt widgets, not GTK+)
**PS:**your table is direct formatted. Though this is irrelevant here, prefer dedicated paragraph styles. Intra-paragraph formatting should be done with paragraph styles.
