To remove the stale object issue(ie..when we run the test script for multiple input,it fails for the second iteration as the object is not cleared at the end of each run)in my script, I have added always search configuration in the designer file. After this my script runs successfully on multiple inputs, but if there is a need to add some objects newly to the same designer file then my designer file will be regenerated and the Always search configuration changes will be lost.
Is there any way to retain the always search configuration remain in the designer file ever even when the designer file is regenerated?
When you generate a UI map there are actually two files that come with it. Firstly, as you've discovered, there's a generated file with all the ugly code that's generated by the coded UI test builder. Of course, making any changes to this outside of the code will regenerate the file. The second file is a partial class that accompanies the generated designer class. This file does NOT get regenerated but as a partial contains all the same object references and properties as the designer file (it just looks empty). You can reference the control you want to add this property to here and it will not be regenerated.
The other alternative to this, albeit probably not a good idea, is to put
Playback.PlaybackSettings.AlwaysSearchControls = true
inside of your test method/class initialize/test initialize. This will force the test(s) to always search for each and every control. As you might imagine, this can have a significant performance impact though when you're dealing with large UI maps or particularly long test methods.
You might also set the control object's search configuration to always search. Keep in mind that this will do searching for this control and all of it's children so I would not advise putting it on a parent with several children, such as the document.
aControl.SearchConfigurations.Add(SearchConfiguration.AlwaysSearch);
Related
I am trying to create a unique id and attach it to a LabVIEW file so that later I can read back that id and know I am looking at exactly the same file. I must be able to generate the id and read it back programmatically. The information must be hidden from the user accessing the file and persist across operating systems and storage mediums.
I was thinking of just adding it into the file 'comment' section, but it appears the Windows no longer supports file comments.
Any ideas?
I would suggest using the Set Tag method on the VI (with persistence) and saving multiple copies of the VI using the Save Instrument method, where each copy would then have its own unique value of the tag. Note that the method is defined as a scripting method, so you would probably need to enable scripting in the LV options to access it.
I don't think there's any API for enumerating tags, so there would be no way to find the value unless you know what the tag is called. Obviously, it's encoded somewhere in the VI file itself, and presumably it would be possible to extract a list of tags if you know the structure of the file, but that's not knowledge I would expect most students to have.
I'm not sure if you can call the set tag method from Python using an external connection to VI server, but certainly the LV code for this should be pretty simple - basically a for loop with ID generation, a couple of method calls and saving a CSV file so you can keep track of which ID belongs to which student. If you use existing IDs, you don't even need to generate and save the IDs.
In Lotuscript you can manipulate design elements - create them, change them, rename them, etc.
Are you able to do the same thing for Xpages and custom controls design elements?
====================================================================
My question should have been clearer. What I want to accomplish is to copy an existing cc and give it a new name, programatically. The app will then close and reopen (or refresh or get rebuilt) so that the app can "see" the new cc. If I copy the cc it will only have one field on it. I will add custom code later. I could just create a new cc with no code in it, that would work too.
I am not familiar with the DXL exporter but I can research it. Using that can I just export the design of the cc to an XML file in a temp directory, use the transform to change the name, and then import the control?
I think the XPage or Custom Control design elements are probably under MISC_CODE or MISC_FORMAT design elements in a NoteCollection.
However, accessing that design element is the easy part. Doing a create / rename / change etc is a much bigger task.
Remember that the XPage or Custom Control XML file is only a starting point:
XPages and Custom Controls also have a .xsp.metadata file, as you'll see with source control.
Custom Controls will also have (and need) a .xsp-config file.
There are corresponding .java files for every XPage and Custom Control in the Local source folder. They're created by a builder based on parsing the XML. I don't think you'll be able to create those programmatically. I'm not sure of the impact of renaming them.
For Custom Controls, even if you can rename the .java file, it's referenced in the .java files of relevant XPages. Updating those is goiong to be a significant task.
The XPages runtime doesn't even use those .java files. Instead it uses the .class files in WebContent\WEB-INF (you need to use Project Explorer view and modify the filter to see those files). This is compiled byte code, so you won't be able to update the .class files for XPages containing renamed Custom Controls, as far as I know.
Even if you can rename the .class files, the XPages runtime almost certainly won't use them until either a Clean (which will overwrite anything you've done) or an HTTP restart. As far as I can tell they're cached.
Depending on your use cases, it's possible not all these points will be an issue, e.g. if you're modifying the XML files and building with headless designer.
I suspect this is why nothing was added to the NoteCollection object or a specific NotesXPage / NotesCustomControl API class added.
In Lotuscript you can manipulate design elements - create them, change them, rename them, etc.
This is only partially true. There is a LS API to create/alter views and outlines. Good luck with other design elements - although they're standard "notes", so you can access their items, in most cases you won't compile them and there will be some problems with signatures (real experience with TeamStudio CIAO).
Your question has two points of view - do you want to alter design elements in design process or alter running application?
To help a designer you can go the way of Eclipse extensions and enrich tools in IBM Designer to help developer. Something like TeamStudio Designer. In this case you need to look for source design elements, mentioned by Paul.
To enrich application you don't need to alter source design elements. IBM Designer transforms XML in source code to a Java code (JSF framework) - so you can generate your Java code from anything you wish. Take a look inside Local\xsp folder of NSF in Package explorer. You will find Java sources made from your XPages and Custom Controls. So if you don't need to work with design elements, go for Java components - they can be built on the fly.
And of course, there is always the option of DXL framework - so you can clone/alter design of the application through XML transformations. Good starting point: http://www-10.lotus.com/ldd/ddwiki.nsf/dx/ls-design-programming.htm
am trying to create a friendlier menu to export models using a file format I created, using the python scripts in Blender 2.63.
Have been checking the API documentation for Blender, also the template examples and haven't figured out how to actually call the Exporter I created, which works ok.
Let me describe a bit more the problem; to export I have to go to File->Export->select the desire format->give a name->Press Export button. I want to automate this process through a menu (like the one provived in the templates, ui_menu); just load/run the script and select Export, the rest should be handled by the script it self. Lets suppose the blend file is MyCoolModel.blend, it will assume the exported file will be placed in the same location, taking the name MyCoolMode appending the correct extension.
By having the Custom menu, which is in one file. Don't know how to call the proccess of the exporter giving the described parameters, don't even know if that's possible.
On the other hand, it might be easier to move the code of the exporter to another module, the Custom Menu, add a button and call a function executing what was described, I just one to get feedback if someone already coded this, and re-use the export module.
In the end I would want to preserve the original export module, in case the artist needs to change the default name of the exporting process, or simply 'cause he wants to do it manually.... Having both versions, trying to re-use the Export would be the best if that's possible, no duplication of code really ;).
I am looking to do something similar, they only thing that I have found that is close enough is the following Scripts/Cookbook/Interface:popup. Of course is still far away from anything close to the export menu, but hopefully it can be extended a lot more.
This is primarily a question of possibilities more than instructions. I'm a programming consultant working on a WSS project site system for my client. We have a document library in which files are uploaded to go through a complex approval process. With multiple stages in this process, we have an extra field which dictates what the current status of the document is.
Now, my client has become enamored with the idea of PDF watermarking. He wants the document (which is already a PDF) to be affixed with a watermark corresponding to the current status, such that with each stage of the approval process the watermark will change.
One method, the traditional method for PDF watermarking, of accomplishing this is to have one "clean" copy of the document somewhere hidden on the site, and create a new PDF from it that has the watermark at each stage of the approval process. Since the filename will never change, this new PDF can be uploaded continually to a public library, always overwriting the old version and simulating a "dynamically changing watermark". However, in the various stages there will also be people uploading clean copies with corrections and suggestions, nevermind the complex nature of juggling around two libraries and the fact we double the number of files stored. My client and I agree that this is not a practical path to choose.
What we would like to do is be able to "modify" the watermark in a PDF, so that we only have to keep one copy of the file. Unfortunately, from what I've seen, in most cases when you make something like a watermark, which in its nature is supposed to be "unmodifyable", you won't be able to edit it later. So, is it possible to have a part of a PDF which cannot be changed by anyone who downloads the file, but can be changed as part of a workflow or other object model process?
PDF Watermarking in SharePoint is a common request. I have written extensively on this topic. See:
Adding a dynamic watermark to a PDF file from a SharePoint Workflow
Adding a (static) watermark to a PDF file from a SharePoint Workflow
Use SharePoint Workflows to inject JavaScript into PDFs and print the ‘open date’
You could use Event Handlers such that code was run every time a document was checked in. In that code you could perform the fixup/check that made the watermark be what you wanted it to be. This assumes you can write code that manipulates a PDF's internal structure such that it has the watermark that you desire.
It sounds to me like you want to allow people to modify the PDF they download, but not modify its watermark. This is probably going to be nigh on impossible if the watermark is embedded in the PDF (afaict) but what if the watermark image is external to the PDF; is it possible to embed a watermark in a PDF that is sourced via HTTP? Then you could embed:
<watermark image="http://sharepoint/site/_vti_bin/docstatus.asmx?id=5">
Of course, I have no idea about PDFs, so this might not be possible but you get the concept.
-Oisin
It is possible to do so if you use third party tool. Then you can put dynamically binded value from your SharePoint metadata, conditions, rules etc: http://www.pdfsharepoint.com
One of our customers has a problem that we cannot reproduce. We programmatically copy a document's properties to a destination file using SPFile.Properties. However, for some reason the file's properties do not match the meta data specified on the list the file is stored in.
Now, we can probably solve this by copying SPFile.Item.Properties (not tested yet), but I am just wondering under what circumstances SPFile.Properties is unequal to SPFile.Item.Properties.
Update: We have just received an update from our customer. Using SPFile.Item.Properties always returns the up to date information. However, we still would like to understand the original question.
There is a slight difference between SPFile.Properties and SPFile.Item fields and the first one is much, much slower to call.
You have most probably seen Microsoft Office document's "properties" window (this one - http://dradisframework.org/images/tutorial/custom_document_properties.png). These are the properties that are read when you access SPFile.Properties. Reading them is slow since there is some code infrastructure that parses the binary DOC file and finds the properties. (takes up to 30 or something milliseconds for every property access) See more here: http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.spfile.properties.aspx
In SharePoint, every item is an SPListItem and its field values (and I don't use the word "properties" on purpose here) are stored in Sharepoint's content database. So, when you access SPFile.Item.Properties, you actually look at the SPListItem to which the file is attached and look at its properties from SharePoint's content database.
What happens behind the scene, when you upload a file having some "Office properties" set, is that SharePoint copies them to same-named fields in SPListItem. (Some information about it here: http://weblogs.asp.net/bsimser/archive/2004/11/22/267846.aspx)
This is why these properties typically have the same value, BUT it only happens if SharePoint knows how to read metadata from your file and write them back. So, in case you put a .txt file in your SharePoint store, you will not get any SPFile.Properties back.
The user will always see the ListItem Properties and not the SPFile properties in a document library. So using the ListItem properties in the copy is the way to go.
I believe this issue is related to the Sharepoint property promotion/demotion feature which enables document properties to be embedded in the physical MSOffice file and travel with it to the client etc. This however is only supported currently for Office file types (to my knowledge).
Jonathan
Trying to find the "official documented" anything for sharepoint is pretty much undoable. :-D. The online docs suck, you are better of using blog entries etc.
P.S. I agree with Alex here. Although an SPFile never exists in a list without an accompanying SPListItem, the connection between the 2 can get corrupted (i.e. being able to edit the list item but the file is not openable). This to me indicates information about the 2 is stored in different locations in the content db. I have had this happen before.