I would like to make a Plugin where the user can select a source and then a target element and get all the parameters and their values.
My problem is: After I selected the source element and got all parameters and values into comboboxes I select the target (via another button). For that the form closes again and after selecting and reopening all the data from the source element is gone.
What would be a correct way to do this?
At this time both buttons close the form run another ExternalEvent to select the element and collect the data.
Can I cache this data (Lists, dictionary with list, dictionary with dictionary with list) or do I have to write it to a file or is there another way?
How do I keep/remember the data I collected when a form closes an reopens?
Thank you for any help
Philipp
There multiple ways of doing this I guess. It is more of a general programming rather than API issue. You basically need to keep the data in memory outside of just the WPF window.
Some options of the top of my head would be
Save the data into file in temp folder and read it when needed (probably a messy solution)
Create & instantiate a class with data to keep in memory and communicate it between different windows etc.
Have a Static Class with appropriate property. Once selecting an element assign it to the property. This should persist within the Revit session. Static Class.
Option 3 should be the easiest to use.
Just use Properties -> Application settings to store the ID of the entity. Then on launch get the combo boxes to auto populate if the ID can be found.
External events are only required when editing the model.
This is assuming your using Visual studio and not sharp develop. If your still using sharp develop it is time to move on to a real IDE.
I think there are a few options. You could use the built in DataStorage that a revit model provides. Here, i made a datastorage entity to store a GUID for a project...
public Guid schemaGuid = new Guid("{5F374308-9C59-42AE-ACC3-A77EF45EC146}");
public DataStorage dataStorage;
public string schemaName = "UniqueProjectId";
public DataStorage dataStorage;
public string SimpleField = "MyProjects_GUID";
public Schema CreateNewDataStorage()
{
Guid newProjectGuid = Guid.NewGuid();
Transaction t = new Transaction(doc, "Make internal storage");
t.Start();
dataStorage = DataStorage.Create(doc);
dataStorage.Name = schemaName;
SchemaBuilder schemaBuilder = new SchemaBuilder(schemaGuid);
schemaBuilder.SetSchemaName(schemaName);
schemaBuilder.AddSimpleField(SimpleField, typeof(Guid));
schema = schemaBuilder.Finish();
entity = new Entity(schema);
entity.Set(SimpleField, newProjectGuid);
dataStorage.SetEntity(entity);
t.Commit();
return schema;
}
Another way would be to write to external database or text file. For something small, SQlite is easy. A temporary text file is also a very simple way to temporarily store data.
Lastly, you could use an Idling event and keep the dialogue box active.
Related
Which series of XML namespaces will You use to serialize an object to XML using WCF?
For example, I have 4 types of Users (left to right) and they have data and references to members in my Users table. This way I could 1/2 have to remove functions and 2 methods because I do not have add/delete methods.
So to end up with code like
public void Save() {
microsoft.Office.Interop.Excel.Application, System.Application.Current.People, System.Runtime.Interop.Microsoft.Office.Interop.Outlook.Application,
Microsoft.Office.Interop.Outlook.Application,
Microsoft.Office.Interop.Excel.Application,
Microsoft.Office.Interop.Excel.Application,
Microsoft.Office.Interop.Outlook.
Microsoft.Office.Interop.Outlook,
Microsoft.Office.Interop.Contact,
Microsoft.Office.Interop.Outlook.
//General methods
}
It makes sense to me for someone to add the notes this method requires but that would allow me to have 2 methods.
Save a new class and create the form to save the new class
Write at least one file, Save or Open for reading?
Add a button about saving the file but then the form with some properties that the functionality should be saved to?
Is this the same? Or is there a better way?
Thanks!
I have a customization to the Invoice and Memo screen, where I have a completely custom table to which I want to write an error log entry. Since this doesn't really fit with how the training addresses the issue - is there a way to do this directly? I noticed that there's a PXInsert<> command - but there's no documentation that I could find, either in the Framework help, or here on Stack Overflow.
I know I can create a Cache object for my custom table's DAC and use the Insert command of that Cache - but I don't know the exact syntax for doing that (and I couldn't find a good fit for what I'm trying to do in the training manuals). Maybe I missed it.
The syntax to create a Cache object (or I think you might be thinking of a graph) is to use PXGraph object. Here is an example:
private void Function()
{
//TargetGraph is the name of the custom page
TargetGraph graph = PXGraph.CreateInstance<TargetGraph>();
//TargetDAC is the name of the custom DAC in your customizations
TargetDAC dac = new TargetDAC();
//Set all data to dac
dac.Log = log;
//Finally insert and perform the save action for the graph
graph.LogView.Insert(dac);
graph.Actions.PressSave();
}
Perhaps someone could add to this answer on how to grab the errors from the page if that is also what you need.
I am xpages enabling an old Notes application which is using profile documents to store translated labels. The translated lables in the notes form are read from the profile document using #GetProfileField depending on which language the user have selected in their profile.
I have read that profile documents are not recommended to use with xpages so I need a better solution for my xpages users. but it is important that users using Notes client still use the "old" profile document solution.
How can I provide these translation lables to my xpages users?
Thanks
Thomas
In addition to Knut's answer there is also the option to "double" your translated labels via the way to prefer in XPages dev by using the localization options as described here: http://www-10.lotus.com/ldd/ddwiki.nsf/dx/UsingLocalizationOptions.htm
You need to split the task into two. First have a function that is called inside the XPage to get the label you are looking for, secondly have a way to provide that value inside the function.
Making a direct call to the profile isn't a good idea since it fixes the way you provide the data (besides potentially creating a memory leak if you don't recycle dilligently). I would see 4 potential solutions:
Define your profile document as additional data source and simply bind the labels to items in the document. Saves you most of the recycling work, but couples tight
Use a SsJS function: getLabel(name). It would check for a scope variable (a Map) and if not found load it - currently from your profile. If application scope is good enough, you touch the profile once only- speed. If you change the loader later on - you don't need to change anything in the XPage.
Use a managed bean. Same approach as #2, only now you can use el data binding. Your bean needs to implement Map
If the labels hardly change do a design time conversion and write the profile doc out into properties files (works nicely with ODP) and use XPages internal mechanism for internationalization
Let us know how it goes
You can use profile documents for this use case as the content gets changed only with new versions of your project probably. So, you can easily live with profile document's caching.
You get the label translation from a profile document with
var doc = database.getProfileDocument("LabelsEnglish", "");
var label = doc.getItemValueString("label1");
doc.recycle();
return label;
You could read all labels in an application scope variable Map too and do your own caching. This way profile documents would get read only once.
if (!applicationScope.labels) {
var map = new java.util.HashMap();
var doc = database.getProfileDocument("LabelsEnglish", "");
var allItems = doc.getItems();
for (var i = 0; i < allItems.size(); i++) {
var item = allItems.elementAt(i);
item.getName();
map.put(item.getName(), item.getValueString());
item.recycle();
}
doc.recycle();
applicationScope.labels = map;
}
Execute the SSJS code above in a custom control which is included in every XPage (e.g. application layout custom control) in before page load event so you can be sure application scope variable "labels" is initialized when you want to use it. You can access the labels easily with EL
applicationScope.labels.label1
We currently have a field which has the wrong ID. the IDs and Internal Names of Sharepoint Fields are readonly on the domain model. I was wondering if there is a way to update them even by using the content database.
One sure way is to delete the field and recreate it. but it already has data and there are thousands of pages. I was wondering if there is a way just to update the IDs and Internal Name without doing the dropping and recreation of fields.
Thanks
Even if it may work, don't do it.
It's:
Dangerous, as you may skip dependencies
Not supported
Recreating the field using some script to keep data is safer.
We ran into the same problem. Messing with the DB was not an option for us (and shouldn't be for you either), but you can work around it. Unfortunately, it will require touching each page to update the metadata.
First, create the column like it should be in the list. Then, you can copy the data from the old column to the new column in a variety of ways:
DataSheet view
Programmatically via web services (don't need to have access to the server)
Programmatically via console app (will need to run locally on the server)
Honestly, writing a small console app will be the quickest. For example:
string siteUrl = "http://server/sitecollection/";
string webUrl = "subsite1/subsite2/";
string listName = "Your List Name";
using (SPSite site = new SPSite(siteUrl))
{
using (SPWeb web = site.OpenWeb(webUrl))
{
SPList list = web.Lists[listName];
foreach (SPListItem item in list.Items)
{
item["New_x0020_Column_x0020_Name"] = item["Old_x0020_Column_x0020_Name"];
}
}
}
Also, it would HIGHLY recommend trying this in a DEV environment first. Just do an STSADM restore from your production environment and test your console app. Then, validate your data and delete the old column!
I would not suggest modifying the content database, since it is:
unsupported (if you do it, Microsoft will not help you when you're in real trouble even if you have MS Premier Support)
very complicated to do. You'd have to update a number of tables and you would never be sure if you actually updated all the required things.
What you can try to do - see if the internal name property is actually "read only" or it is defined as "friend" and you cannot call it from a different code assembly. If it's the latter case, you can use .Net reflection to set the property value. See this MSDN documentation link for details.
Edited by OP.
My program is in need of a lot of cleanup and restructuring.
In another post I asked about leaving the MFC DocView framework and going to the WinProc & Message Loop way (what is that called for short?). Well at present I am thinking that I should clean up what I have in Doc View and perhaps later convert to non-MFC it that even makes sense. My Document class currently has almost nothing useful in it.
I think a place to start is the InitInstance() function (posted below).
In this part:
POSITION pos=pDocTemplate->GetFirstDocPosition();
CLCWDoc *pDoc=(CLCWDoc *)pDocTemplate->GetNextDoc(pos);
ASSERT_VALID(pDoc);
POSITION vpos=pDoc->GetFirstViewPosition();
CChildView *pCV=(CChildView *)pDoc->GetNextView(vpos);
This seem strange to me. I only have one doc and one view. I feel like I am going about it backwards with GetNextDoc() and GetNextView(). To try to use a silly analogy; it's like I have a book in my hand but I have to look up in it's index to find out what page the Title of the book is on. I'm tired of feeling embarrassed about my code. I either need correction or reassurance, or both. :)
Also, all the miscellaneous items are in no particular order. I would like to rearrange them into an order that may be more standard, structured or straightforward.
ALL suggestions welcome!
BOOL CLCWApp::InitInstance()
{
InitCommonControls();
if(!AfxOleInit())
return FALSE;
// Initialize the Toolbar dll. (Toolbar code by Nikolay Denisov.)
InitGuiLibDLL(); // NOTE: insert GuiLib.dll into the resource chain
SetRegistryKey(_T("Real Name Removed"));
// Register document templates
CSingleDocTemplate* pDocTemplate;
pDocTemplate = new CSingleDocTemplate(
IDR_MAINFRAME,
RUNTIME_CLASS(CLCWDoc),
RUNTIME_CLASS(CMainFrame),
RUNTIME_CLASS(CChildView));
AddDocTemplate(pDocTemplate);
// Parse command line for standard shell commands, DDE, file open
CCmdLineInfo cmdInfo;
ParseCommandLine(cmdInfo);
// Dispatch commands specified on the command line
// The window frame appears on the screen in here.
if (!ProcessShellCommand(cmdInfo))
{
AfxMessageBox("Failure processing Command Line");
return FALSE;
}
POSITION pos=pDocTemplate->GetFirstDocPosition();
CLCWDoc *pDoc=(CLCWDoc *)pDocTemplate->GetNextDoc(pos);
ASSERT_VALID(pDoc);
POSITION vpos=pDoc->GetFirstViewPosition();
CChildView *pCV=(CChildView *)pDoc->GetNextView(vpos);
if(!cmdInfo.m_Fn1.IsEmpty() && !cmdInfo.m_Fn2.IsEmpty())
{
pCV->OpenF1(cmdInfo.m_Fn1);
pCV->OpenF2(cmdInfo.m_Fn2);
pCV->DoCompare(); // Sends a paint message when complete
}
// enable file manager drag/drop and DDE Execute open
m_pMainWnd->DragAcceptFiles(TRUE);
m_pMainWnd->ShowWindow(SW_SHOWNORMAL);
m_pMainWnd->UpdateWindow(); // paints the window background
pCV->bDoSize=true; //Prevent a dozen useless size calculations
return TRUE;
}
Thanks
Hard to give you good recommendations without knowing what your program shall do. I have only a few general remarks:
Your InitInstance does not look very messed up for me. It's pretty much standard with a bit of custom code in it.
Also the ugly construction to retrieve the first view from the application class (the chain GetDocTemplate -> GetDoc -> GetView) is standard to my knowledge. I actually don't know another way. You might think about moving it into a separate method like CChildView* CLCWApp::GetFirstView() but well, that's only cosmetic as long as you need it only at one place.
What you are doing and which data you are placing in your Document class and in your View class(es) is more a semantic question if you only have one view. (You have only one document anyway because it's an SDI application.). From a technical viewpoint often both is possible.
But to be open for (perhaps) later extensions to more than one view and to follow the standard pattern of a doc/view architecture there are a few rules of thumb:
Data which exist and have a meaning independent of the way to present and view them (a document file, a database handle, etc.) belong to the document class. I don't know what your pCV->OpenF1(cmdInfo.m_Fn1) ... and so on does but if it's something like a file or filename or a parameter to be used to access data in any way OpenF1 might be better a method of the document class.
Methods which do any kind of data processing or modification of your underlying data belong to the document class as well
Data and methods which are only needed for a specific way to display a document belong to a view class (for instance a selected font, colours, etc.)
On the other side: If you have a fixed number of views which open with the document it might not be wrong to put view specific data into the document, especially if you want to make those view parameters persistent. An example would be a file with some statistical data - your document - and a splitter frame with two views: one displays the data as a grid table and the other as a pie chart. The table has "view data" describing the order of and width of columns, the pie chart has data to configure the colours of the pie pieces and the legend location, for instance. If you want to make sure that the user gets the last view configuration displayed when he opens the document file you have to store these view parameters somewhere. It wouldn't be wrong or bad design in my opinion to store those parameters in the document too, to store and retrieve them from any permanent storage, even if you need them only in the view classes.
If your application allows to open an unlimited number of views for a document dynamically and those views are only temporary as long as the application runs, storing all view configuration parameters directly in the view classes seems more natural to me. Otherwise in the document you would need to manage any kind of dynamic data structure and establish a relationship between a View and an entry in this data structure (an index in an array, or a key in a map, etc.)
If you are in doubt whether to place any data in the document or view class I'd prefer the document because you always have the easy GetDocument() accessor in the View class to retrieve members or call methods of the Doc. To fetch data from the View into the Document requires to iterate through the list of views. (Remember: Doc-View is a 1-n relationship, even in a SDI application.)
Just a few cents.