To clarify, it might be a time related issue which means that you might hide columns programmatically before some other refresh happens. This one might be similar to https://bugs.eclipse.org/bugs/show_bug.cgi?id=411224 which I am looking at the next days. But you could check your timeline on creation.

Also you are exposing API on calling the hide method on the layer directly. Well, the method is public and the direct call was valid before. So I can't blame anybody for using it directly. But to perform actions in the NatTable we suggest to use the corresponding commands rather than calling the methods on the layer directly. So you might want to try calling

i tried to execute this command before and after calling nattable.configure() (with both versions 0.9 and 1.0.0)
with the same result in all 4 cases: no change in visibilty of any columns.
note that i do log the visibility in the call getBlackListing() and it returns me the indices (so my getBlackListing() function is valid)

well i do set my blacklist (as default)
if another config is available i load it using natTable.loadState
when i test there is no other config available, so nothing gets changed.
i only use the data, which gives me the blacklist, to synchronous visualize a formular, which is working correct (this only reads data, it cannot change any values)

i downloaded the latest snapshot, as you mentioned, and tested (unchanged code). its working now!
thanks for fixing it!

'synchronous visualize a formular' <- i wrote a formular component which displays the same fields, which the table renders, as a formular. if the user changes visibility of a column, also the field in my formular gets hidden/displayed. if its reordered in table, the position in the formular is changed too (it repositions the field without disposing and creating a new one [that is what most components do which display formulars])

Great! The issue was related to firing the ColumnReorderEvent. The Column*Layers treated it as a whole refresh, which simply resetted the states. Now it is possible to be more specific in telling what columns have changed and need to be refreshed.

it is really hard to tell you why something is not working without knowing your whole infrastructure. When I asked you if something happens afterwards you said no. Telling me later that you are firing a ColumnReorderEvent with negative positions to synchronize with some other controls. I still don't understand why you are firing a ColumnReorderEvent with invalid positions to synchronize something. Possibly the event is cleaning up as it refreshes the NatTable completely. Maybe it is something else. Debugging code in mind that I haven't seen at any time is really hard. And IMHO the only way to get arround your issue is debugging.

The breakpoint should be in the ColumnHideShowLayer.handleLayerEvent(). Check what is going on there after your hide command. Maybe then you will find what is going on.

i tried to extract the minimal needed stuff for my table/form generator.
resulting in a plug-in project, which contains needed stuff.
by changing one line of code you can see the result between working and not working.

if you give me your email address i can send the zip file. (no attachments in this forum for me and all filehosts are blocked by my company)

I really like to help people using the project I am participating. But getting your code, debugging stuff and trying to fix your special issues is beyond scope.

a) I looked into your issue and found out that there is an issue I solved with a bugfix. This bugfix now allows you to specify which columns have changed (added/deleted) and refreshing only them instead of perfoming a whole refresh which resets the layer states.
b) I verified that the intended functionality works by adding the lines of code in a former post to an existing example
c) I gave you some hints where to have a look

When asking me for such intensive help, you should consider that this is not my full time job I earn money with. I work on an open source project in my spare time because I like it. There is no duty unless I feel like. I am a consultant, which means I earn money by consult, design, implement and fix stuff. This is where I get my money from. And I have really a lot to do at the moment.

So if you don't ask me for payed support, please investigate your issue on your own and report a bug if there is any. But as I said before, I think it is a time related issue in the things you are doing.

If you ask for payed support, you can find my email-address in the slides of my NatTable talks online.

i'm sorry. it was not supposed to be offensive or something like do my job.
showing a (declared) example which shows that nattable does not react as expected when a command is given is of your interest too.
i'm using nattable as a key component and i am more than happy that you (and others) developed this component.
thats why i report errors which i find. complexity of nattable is at a limit which i do not overview (as i am not into it)

so i just wanted to show you that nattable does behave different if you have state A, then change stuff in the bodystack and get state B, whereat there is no change with the Command (in my case)

i understand that you do not earn money with this.
but actually my boss will not give me money for investigating in (lets call it strange behaviour rather than a bug)
as i got the workaround in the bodystack (so the problem for me is fixed by now - unless changes in future will block this functionality)
if it would be up to me i'd pay you for finding it

anyway - thanks for your help! and iff i find a solution to it i'll let you know.

I understand your intention and I'm glad that you report such issues. Don't missunderstand me. For me it just sounds like a special case that is beyond default use cases that are handled by NatTable. Of course we want to be as integratable as possible, but in some cases our capabilities are limited.

If you think it is a bug, please open a ticket and attach your example. Maybe we will find some time. But at the moment there is not enough room for this and IMHO it is not critical.