I developed WIT custom control. The control used xml serialization to store complex data as value. One of must have requirement is printing support. As it expected the control value is displayed in serialized view when user tried to print work item form that contains the control.
I couldn't find any way to deserialize the value of the custom control and set layout before printing.
Does anybody know how it can be done?
The way this is normally done is:
create a backing field containing the xml data
create a second field containing the display data
When the display data changes, update the backing field accordingly and vice versa using the when rules. (Check out the Priority field for an example on how you could do this).
Now it's easy to print something else than xml, but it's still hard to create a graphical representation.
Related
I guess that I am really missing something on the datasource in a custom control. When I create the custom control I have no idea what the name of the datasource on the XPage is going to be. I have added a custom property to the custom control to pass using the Type com.ibm.xsp.domino.model.DominoDocumentData and the Method Binding Editor, and this sort of seems to work if the Custom Control does not contain Custom Controls. At which point either I am getting lost or the XPage/Custom Control binding is getting lost.
Here is what I am trying to do I have created a Tab Table using the Extension Library and have placedd it on a cc. I have set up several tabs on it. Because the amount of information on each tab is pretty extensive I thought I would create a custom control for each tab. Then I ask the Yes/No question on almost every line I created a ccYN custom control, plus a couple of other ones as well because they can be reused and simple bound to a different fieldName that I have set up in the cc Properties. I see where others have said that if the datasource is defined for the XPage that it is available to all of the cc's, the method above seems to work for the first level but deeper than that leaves me or the XPage really confused. I have searched the internet/read Mastering Xpages but am not much further ahead.
It has been a long drawn out process but I think I have it now. On the Custom Control create a Property definition with a type of com.ibm.xsp.model.ModelDataSource with an edit type of String and call it something say ccDataSource. Then bind the the ccDataSource to the datasource of the XPage that contains it when it is know using SSJS so say it is myDataSource.
If the Custome Control is contained in a custome control and the datasource needs to be passed through another level the the binding is compositeData.ccDatasource or ?? whatever the outer datasource Property definition for the Data Source is.
There might be a cleaner way of doing this but I have not found it.
Not sure if you're still looking for an answer, but you can use the data source of "currentDocument" in a custom control. This assumes that the custom control is in a panel with one document data source, or in an XPage with one document data source.
I created a custom control that is binded to a a Domino Document data source. I embedded it in a page so that I can display it in a Dojo dialog. It has 2 properties: dialogId and docId. The document data source's Document ID property is set to compositeData.docId. In the page, I set the docId property to a viewScope variable, that will be set when an entry in a view is clicked. What I want to accomplish is that the dialog will display the document that the current view entry (that was clicked) represents. But it seems that the compositeData.docId is not set on partial or even full refresh. Is there a way to do this that the custom control will be binded to the document? I need to have this binding so that I can easily do a server-side validation when I submit the dialog. Or if there is another way, can you also put it here? Thanks a lot!
set the datasource as the document, and then edit mode, then you have a place to compute the doc id, i usually compute the doc id to a viewScope, that i set when i click the item in the repeat control
More details here.
I would prefer the DocId to be transfered via the custom control parameters rather than a Scope variable. Using the Scope breaks the custom control design principle of being self contained. You can use the yourCC.PropertyMap to actually update a value, so the hand over of the parameter will work - of course your control then needs to be refreshed so the data source is recomputed. Hope that helps.
I'm trying to create a Mac OS Core Data application that has an array of parent objects (called Levels) each of which contains a collection of child objects (called Blocks) via a one-to-many relationship. I have a table view successfully controlling the array of levels, and a custom view object that draws the blocks graphically based on positions held in x and y properties of my Block model class. I can add blocks to the currently selected level, remove them, select and move them around in the custom view, and have bound text fields to various other properties of the Block class which I can use to edit those values. All of this information is successfully saved and restored to and from the core data repository with no issues output to the debugger. Wonderful. I've used an NSArrayController for the Levels and another for the Blocks that is bound to the current selection of the Levels array controller, in what I've read is a pretty standard way.
Now, my Block class is actually an abstract class, and what I actually instantiate are various child classes of Block (eg RedBlock, GreenBlock, BlueBlock classes). Each sub-class has a separate set of properties that only apply to that type of block (so RedBlock has a "text" property that none of the others have, BlueBlock has an integer "value" property, etc). I want to create an inspector that will change depending on the type of the Blocks that are currently selected in my custom view. To try this, before I start creating subviews for each type of Bock, I have created a text field that I want to bind to the currently selected RedBlock's "text" property, preferably showing nothing when Blocks of other kinds are selected. This is where I'm stuck. I've added another NSArrayController in Entity mode with RedBlock specified as it's type so I can bind to the "text" property, and tried adding a filter predicate based on the class type. I've also tried various other configurations and bindings, but I'm either getting exceptions, or corrupt values in the text field that I bind to that controller, or other weird bugs and general brokenness.
I've googled around for an example of an inspector that can cope with a heterogenous array of objects (as that's essentially what I'm trying to do) but so far no luck.
So, my question is - am I going about this the right way? Should I be trying to create an NSArrayController that filters the selected items in my Blocks array controller somehow? If so, should that be straightforward or is there some trick that I've missed? If not, what is the best way to do this?
This approach should work, provided you limit the inspector to displaying view which bind to properties which apply to the entire selection. You don't need a second array controller.
To test the simple example, try creating a data set with only blocks, see that your bound control loads without raising exceptions, and that it updates the object correctly.
Once that is working, create separate views for each type, and display and hide them when the selection will change. Again, if you have a heterogenous selection, hide them all.
I have a class named as transaction in which one attribute is transactionDate which is of type NSDate.
I am using NSArrayController to display a list of transactions in a table view.
My requirement is-
I want to show date in first row in a
text field labeled as "From" and date
in last row in a text field labeled as
"To".
My questions is-
Can I achieve this via binding in IB?
If yes then how?
Thanks,
Miraaj
Yes, you can do this (or something like it), see the #min and #max array operators.
Here's how to do a very simple version of this:
Open Interface Builder - create a new application
Add an NSArrayController, set it to automatically prepare content.
Add a Table, label the two columns "name" and "age"
Add a Button (labelled "+") and two Labels (change name to maxval, minval)
Wire up the NSArrayController bindings as follows:
Here's the application running (just in interface builder "simulate" mode). To use it, click + then click on the top row of the table and put a name in the first column and an age in the second. Then repeat for a few more people.
This all looks a bit cryptic, but it is sufficient. I added the labels "Max Age" and "Min Age" for clarity in my version.
Unfortunately this is not something Bindings is particularly good at. You could achieve it but it would be very hacky.
The NSTableViewDataSource protocol is still a perfectly relevant and valid way to provide data to a table. In cases like these (where you're not just presenting a straight-vanilla set of uniform data to a table) the data source protocol is the only sane way to solve the problem. This way you're in complete control of what the table displays.
The only "hard" part is that, if you're using Core Data, your data source class will need to observe the Managed Object Context for changes and reload the data (either -reloadData to refresh the whole table or use -reloadDataForRowIndexes:columnIndexes: to cherry pick the rows you want to refresh).
I have some data Grid Views and I want the user to be able to keep changes he does to them. Not the Data changes, only the layout changes, like the width, the hight, the order of the columns and maybe the visibility of them. I don't care if it will be automatic or by clicking a button...
Edit: I found a way to do this using Settings.I have added the settings file, but I have no idea of how I'm supposed to add column order or column size in those settings
The kind of formatting information you want to save can be found in the various properties of the DataGridGiew. You may have to spend some quality time with its object model documentation, but you should be able to find most of what you're looking for.
For example, to save the way the rows have been sorted, you can persist these two properties:
DataGridView.SortedColumn tells you on which column's values the rows were sorted.
DataGridView.SortOrder tells you the order (i.e. ascending or descending)
And you should be able to find info about column widths and order on the members of the DataGridView.Columns collection.
I think it's a matter of preference whether you record these values all at once (e.g. click a "save settings" button) or one by one in event handlers as the properties get changed. I like to save them automatically when the form is closed w/out any action by the user. It's been a while since I implemented anything like this, but I recall the app settings being a pretty handy place to keep this sort of info. In the Project Properties Settings designer, just define settings for the stuff you want to keep (make sure to set the Scope to "user"). Then assign and load actual values in your code at run-time, like so:
// e.g. you defined an integer user setting at design time called ColA_Width, to
// hold the value of the width of "ColA" in your DataGridView.
// Use this code to save the value (either in a specific event handler, or a
// global "save settings" routine).
Properties.Settings.Default.ColA_Width = MyDataGridViewInstance.Columns["ColA"].Width;
Properties.SEttings.Default.Save();
// Then you'd reverse the assignments when the app next loads so that the saved
// settings are "remembered" between user sessions.
MyDataGridViewInstance.Columns["ColA"].Width = Properties.Settings.Default.ColA_Width;
The only caveats I can recall are that some of the DataGridView property values are not straightforward to save as strings (remember that your user settings are ultimately saved as XML), but it really depends on what sort of settings you're saving.
I am assuming you mean the end user, if so then I would store that info in cookie/database and pull it on load to customize their experience.
In each of your event handlers for resizing/sorting you could have a helper function that writes the layout instructions to a storage medium like a db, registry, xml, config, etc... and read those instructions to draw the interface when the application loads.