Forum Discussion
Can you use StructuralTypeDescriptor's without capabilities.json?
When making a Custom Visual: in the documentation about objects and properties (https://docs.microsoft.com/en-gb/power-bi/developer/visuals/objects-properties) it specifys that the "type" is either a ValueTypeDescriptor or a StructuralTypeDescriptor.
However, in schema.capabilities.json, even in the latest API version, (v2.6.0) only fill and fillRule are allowed.
If I try and add another type like "image" into my capabilities.json, I get the error "Invalid capabilities" when I try to build the visual.
Is there any way to use the other StructuralTypeDescriptor's from PowerBI-visuals.d.ts ? "image" and "geoJson" types in particular would be useful.
I can make-do with a series of custom string properties, but it makes more sense to use the existing interfaces.
Thanks!
Hi c-duff,
Unfortunately not - if the capabilities.json does not validate against the prescribed schema, then you'll run into these issues and the visual just won't build.
For now, the workarounds you're specifying (string properties and parsing them to the desired types on enumeration, and back when update) are the way to go, but I agree this would be a useful addition to the user experience. Perhaps you can create an enhancement request for it?
Another alternative would be to consider using advanced edit mode (EDIT: correct link) to build a UI component for these properties specifically for the end user, and handle the read/write from the capabilities accordingly. The d3.js visual does something like this (albeit with text boxes, but could be modified to use other widgets):
- js and css objects in capabilities
- Show/hide containers based on mode
- Persistence from editor to objects
Regards,
Daniel
If my post helps, then please consider accepting as a solution to help other forum members find the answer more quickly 🙂
3 Replies
- dm-pSuper User
Hi c-duff,
Unfortunately not - if the capabilities.json does not validate against the prescribed schema, then you'll run into these issues and the visual just won't build.
For now, the workarounds you're specifying (string properties and parsing them to the desired types on enumeration, and back when update) are the way to go, but I agree this would be a useful addition to the user experience. Perhaps you can create an enhancement request for it?
Another alternative would be to consider using advanced edit mode (EDIT: correct link) to build a UI component for these properties specifically for the end user, and handle the read/write from the capabilities accordingly. The d3.js visual does something like this (albeit with text boxes, but could be modified to use other widgets):
- js and css objects in capabilities
- Show/hide containers based on mode
- Persistence from editor to objects
Regards,
Daniel
If my post helps, then please consider accepting as a solution to help other forum members find the answer more quickly 🙂
- c-duffFrequent Visitor
Thanks dm-p !
I thought that might be the case. Advanced edit mode is new to me, I was doing the same thing with a boolean property, but advanced edit mode is taylor made for this kind of thing.
FYI, I think you linked to the wrong page for advanced edit mode. Here is the documentation for those that follow.