How can I determine if a tree row in Tabulator is expanded or collapsed? I'm using version 4.9, the current. The best I could come up was digging into the implementation details:
row._row.modules.dataTree.open
But I'd prefer something using only the documented API. The best I could come up with was:
row.getNextRow().getTreeParent() === row
// (With special handling when getNextRow() is false)
I don't think there is currently a built-in method to check expanded state. You could row.getElement() and manually check for the dataTreeCollapseElement. You can also create a Github Issue to suggest the addition of one.
You are right to avoid referencing _row, as any properties beginning with an underscore are to be treated as private properties. These are undocumented and could change at any time, and aren't meant to be referenced outside Tabulator's source code.
Related
My app has a flexible column layout with the list report displayed initially, and then switch to two columns when I click on an entry in the list report. This works fine so far with one way binding with backend model. But when I switch to two way binding then the click on entry does not show the second column. I am using the following code to switch the layout to two-column.
this.byId("flexibleColumnLayout").setLayout(sLayout);
Inside the setLayout() , I see some code that speaks about two-way binding. I am not an expert though to understand that level.
Anyone has fixed such an encounter? Appreciate your help. Thanks...
this.byId("flexibleColumnLayout").setLayout(sLayout);
This is resovled. The setLayout method is triggering some code where is going through some two way binding check and did try property binding checking against backend model, which is not correct. Instead binding the control to local json model did work. Thank you all!
I have an attribute of type pim_catalog_number, but I need to change this to pim_catalog_simpleselect. I cannot change this in Akeneo and if I try to overwrite it by importing a new attributes-file I get the notice that I am not allowed to change the type.
But I have a scenario where I need to do this. So what's the proper way to do this? I can imagine doing some direct SQL queries, but what are the consequences of changing the type directly in the database?
For now the only solution is to export the product values, delete the attribute, create the attribute with the right type and then re-import the products.
We are currently working on a proper solution to do that, but with all the feature of the PIM involved (history, rules, proposals, search, etc) it's not an easy task. We dedicate 1 dev full time on this task for the next three months to come up with a nice solution.
I'm writing a few custom CIFilters for a program. Based on the fact that CIKernel's kernelsWithString: will take multiple kernels from the same file (and a few similar clues I can't recall right now), it seems like I could provide them all in 1 plugin. Am I barking up the wrong tree, or is this doable?
I made an admittedly flawed attempt at this, and the 2 filters do show up. However, one was flawed, and using [[CIFilter filterWithName:filterName] attributes] on it produces null for the parameter list.
I believe I've fixed it now, but [CIPlugIn loadAllPlugIns] "loads newly added image units, but image units (and the filters they contain) that are already loaded are not removed." Either my fix is being ignored, or I haven't actually fixed it. Unless somebody knows a method that unloads a filter (which the Core Image Programming Guide implies is possible), I can't be sure without rebooting.
Apparently I had a misunderstanding of how the CIPlugin system works: it is not global. That is, each program's loaded plugins are independent of other programs'. So to update a plugin, simply close all programs that are using it, and replace the plugin.
To answer the main issue, yes, it's fairly easy to put multiple filters in 1 plugin.
Each filter needs it's own XxxPlugInLoader : NSObject <CIPlugInRegistration> class and Xxx : CIFilter class. (The filters' bundleForClass appear to all load from the same bundle.)
The kernels can be in the same *.cikernel file or not, but if together avoid loading the *.cikernel for each filter (it won't hurt, but it's inefficient).
Set up 1 Description.plist and 1 Description.strings, with the info for all the filters. In the plist, each filter's CIFilterClass entry must match the CIFilter class defined above. Each filters CIAttributeDescription entry is a key into the strings file.
According to the code sample on MSDN (http://msdn.microsoft.com/en-us/library/hh552522.aspx) any custom property data that you need to get out of your control should be in a semicolon delimited string in the AccessibleObject's Description property. This does not seem right to me at all. This seems like just a quick and dirty trick to get it working. What is the correct way to get the value of properties from custom controls? And if this actually is how you're supposed to do it, then how are you supposed to set those properties using the SetPropertyValue method? The example in the link above just throws a NotImplementedException in SetPropertyValue.
Since the IAccessible interface has only a limited number of properties the best solution is to cram any extra information into the Description property (that's what they do at the company I work at, and our developers don't work quick and dirty :) ). To modify the return value of this property you have to implement the Iaccessible interface on your control. Or, since you only want to modify the Description property you only need to modify that property and leave the rest to the proxy (I'm not sure how this works exactly but there are tutorials for it on MSDN).
The SetPropertyValue method in the UITestPropertyProvider is for the UItestControls. By overwriting it you can modify the way CUIT interacts with the control during playback. For example, if you overwrite SetPropertyValue for the Text property you can change the way CUIT types strings into the control.
I have a reason to prefer my plugin to be registered on post-op but I'd need to put something in it (change a field to another value). Do I really have to register it on pre-op or can I shove my update into it despite that the operation has been carried out already?
I'd prefer to avoid firing up an update. The code logic might get a bit crowdy and confusing by that, since there'll be a lot of stuff to do upon a "real" update.
Changes made to the target entity in post-op will not end up in the database unless you run an update manually.
You could consider breaking up your plugin into two. One to change the field in pre-op and one to do whatever it is you're doing in post-op.
Plugins can share data: http://msdn.microsoft.com/en-us/library/gg328579.aspx