I have a quite large now program using [Sharepoint] 2013 fondation and CSOM. I use clientcontext.executequery with success.
I would like to work with executequeryasync but my "clientcontext" does not present that method neither in intellisense, nor accepted at compile time if I type it directly. Only executequery is present.
If I "f12" on my clientcontext, I fall in the SP ClientContext class which has an executequery but no executequeryasync.
.Net 4.5 and 4.5.1, same result
What am I missing ?
Thanks a lot !
Do you make sure the SharePoint script file 'sp.js' is loaded before your code runs?
SP.SOD.executeFunc('sp.js', 'SP.ClientContext', yourFunction);
The asynchronous version is only available in Silverlight. See the mentioned assemblies in the corresponding MSDN article.
Related
How to clean SSJS (Server Side Javascript) in Domino server after someone used javascript prototype in a nsf?
Mark Roden discovered a huge weakness in XPages SSJS: (thanks to David Leedy for tell me about this and show me the article).
If you have the following SSJS code:
var dummyObj = {}
dummyObj.prototype.NAME = "Johann"
XPages SSJS doesn't care that you uses var (var means the variable must be local) and it makes dummyObj.NAME visible in the whole server with the value Johann. So if another nsf in the same server uses a var with the same name it inherits the whole prototype:
var dummyObj = {}
println(dummyObj.NAME) /*prints "Johann" */
This is a huge bug (one that makes unreliable XPages SSJS IMO). Even if you don't use prototype at all, if someone else in his application do something like this:
String.prototype.split = function(){ return "I broke this method" }
It will broke all applications in the same server that uses the innocent split().
So, the question is: if someone "by mistake" writes the following SSJS (XPages Server Side Javascript) in a NSF:
String.prototype.split = function(){ return "I broke this method" }
How can I fix String.prototype.split() to his original value?
As Mark Roden said, restarting HTTP task doesn't fix it.
///////////////////////////////////////////////////////////
Edit 1: Why I think this is a huge bug:
I'm a Javascript fan but IMHO #MarkyRoden has discovered a huge bug in SSJS. Shims and polyfills aren't really the main problem. Eval is known to be a bad practice but the prototype object is a fundamental element of basic Javascript. It's the standard and preferred way to add methods to Javascript classes, it's also needed for inheritance and all kind of OOP stuff. So you will need some kind of namespace at server level in order to avoid collisions. All this is really bad but the huge problem is that just a line of code in one application can broke all applications in a server. Yes, you can trust in your developers but one of them can write a bad line by mistake and also a Domino server can have hundreds of applications from different software vendors. Set the responsability in code reviews is not a reliable enought procedure. Maybe it's time to have a real javascript engine in SSJS, like V8, Spidermonkey, Chakra or Rhino. As a workaround, I'm thinking in something like Tommy Valand's idea with Rhino in SSJS.
Edit 2: It's even worse. You can do things like:
prototype.importPackage = null
or
prototype.Array = null
As you can see in #SvenHasselbach's article: http://hasselba.ch/blog/?p=1371
Edit 3: IBM: you told me I could use SSJS. COME ONE! PLEASE FIX THIS, it's AWFUL. Please let's officially report this issue to IBM.
You can reset the SSJS interpreter with the following Java code:
FacesContextExImpl fc = (FacesContextExImpl) FacesContextExImpl.getCurrentInstance();
UIViewRootEx2 uiRoot = (UIViewRootEx2) fc.getViewRoot();
JSContext jsContext = uiRoot.getJSInterpreter().getJSContext();
jsContext.getRegistry().init(jsContext);
This reinitializes the registry and all prototype functions.
EDIT: Changed the declaration of fc to the correct type.
EDIT 2:
Here is the SSJS version:
var uiRoot = facesContext.getViewRoot();
var jsContext = uiRoot.getJSInterpreter().getJSContext();
var reg = jsContext.getRegistry();
reg.init( jsContext );
Does I understand you correctly, that you want to clean up the SSJS interpreter to avoid a collision with your own prototype extension?
Just to clarify the answer above: This reinitializes the SSJS interpreter once. And only once.
You have to do this over and over again, because directly after reinitializing, another application on the server can overwrite the prototype functionality again. That's why this is not a real solution, it is an answer to your initial question.
It will have interessting consequences if another application will do the same while your code tries to use your extension...
try to do a Restart Task Http instead
tell http restart will not do a full restart of the http task
I meet the following issues after migration from VSTT2010 to 2013:
all my ....WaitForControlReady(3000); throw exception object reference not defined to object reference
e.g:
UIMap.UIIdentificationWindowWindow.UIIdentificationDocument4.WaitForControlReady(3000);
Is waiting for a popup to be displayed
MonNavigateur.WaitForControlReady();
with:
public static BrowserWindow MonNavigateur; declared in the class
and: MonNavigateur = BrowserWindow.Launch(new Uri(sAppConfigExtranetUri)); in MyTestInitialize() method
I worked like a charm in VSTT2010 ;(
The temporary workaround used is to replace all my WaitForControlReady(); with a not satisfying Playback.Wait(x000);
Anyone has an idea to solve this problem please?
Make sure you upgrade your reference assemblies to the latest version. WaitForControlReady() should be a part of the Microsoft.VisualStudio.TestTools.UITesting assembly. Version 12.0 would be required to run in VS2013.
I am using MsiGetProperty to get string parameter value from the installer.
And after that I am calling a managed dll and I pass the that value:
nvBufferSize = MAX_STRING;
MsiGetProperty (hMSI, "DBHMS", sDbHost, nvBufferSize);
when I pass the value of sDbHost is like this when I receive it from managed code:
srvdata-02NULNULNULNULNULNUL......
however in the interface I wrote just "srvdata-02".
With that same code it was fine with Installshield 2010, now I am upgrading it to installshield 2012.
Do you have any solution with that please?
There were some behavior changes to MsiGetProperty awhile back. Try setting nvBufferSize to MAX_SIZE instead of MAX_STRING. Also check the return code of MsiGetProperty to see if it equals ERROR_MORE_DATA or if it's returning some other code. Finally check the value of nvBufferSize to see how many bytes are needed.
BTW, if you are just trying to marshal a property over to managed code, you might want to conisder looking into Deployment Tools Framework (DTF) in Windows Installer XML (WiX). This is a very nice SDK that allows you to write managed code custom actions and package them up as if they are native Win32 libraries. InstallShield can then easily use this as an MSI DLL custom action.
DTF provides an interop library and a session object that can be used like:
Deployment Tools Foundation (DTF) Managed Custom Actions
Reasons DTF is Better
As ridiculous as it may seem, here's a working InstallScript solution for you:
nvBufferSize = MAX_STRING;
nResult = MsiGetProperty( ISMSI_HANDLE, szPropertyName, svValue, nvBufferSize );
if( nResult = ERROR_MORE_DATA ) then
MsiGetProperty( ISMSI_HANDLE, szPropertyName, svValue, nvBufferSize );
endif;
The first attempt returns the actual buffer size needed. If it is more then max string (1024?), the second call gets the whole thing.
Alternatively, I found I could assign nvBufferSize to larger value right off the bat e.g. 4096 and use that with a single call (assuming the data was no longer that limit). The double call, however, is more fool proof.
According to: https://msdn.microsoft.com/en-us/library/aa370134(v=vs.85).aspx the api function is actually designed to return the buffersize by passing an empty literal ("") instead of a string variable. InstallScript 2013 throws a compilation error at you if you try that though...
I'm triying to use Media Foundation to play mp3 file and I have a problem getting PresentationDesctiptor using CreatePresentationDescriptor method
What am I doing:
Start MF using MFStartup
Create session using MFCreateMediaSession
Create SourceResolver using MFCreateSourceResolver
Create MediaSource using CreateObjectFromURL from SourceResolver
Create topology using MFCreateTopology
Trying to create PresentationDescriptor using CreatePresentationDescriptor from MediaSource
When I call CreatePresentationDescriptor no error/exception occurs it just stands there and does nothing. When I pause Visual Strudio it indicates that program is still waiting for method to finish. What am I doing wrong ?
I did not metion that I use C# for this (did not think this was relevant)
The problem was that when importing com interfaces in C# you need to import all methods of interface not only those that are called. Some methods can call not imported methods and cause Access Violation that is not reported to Visual Strudio debugger and as a result it seems like method is never finished invokink.
I am in Mongo-C# environment and we have been coding against Mongo for a while using Mongo 1.3.x DLL. Recently, I updated it to be 1.4.2 and everything else was fine until I faced a problem where I noticed that while previous version of Mongo DLL was treating
update.SetWrapped(property.Name, value);
all file when value was null but the recent version does not like it and it throws nullreference exception.
Problem here is that I would like it to be able to accept Null values. has anybody faced this problem before? If yes, how did you handle that?
There was a breaking change when this was introduced. You need to use BsonNull.Value for this. So, your code would look like this:
update.SetWrapped(property.Name, BsonValue.Create(value) ?? BsonNull.Value);
I believe you should have been able to pass C# null to Update.SetWrapped<T> because T is a POCO and not a BsonValue and the serializer for T would decide how to serialize C# null.
I've created a JIRA ticket for this:
https://jira.mongodb.org/browse/CSHARP-486
Note that while C# driver versions earlier than 1.4 did not throw a NullReferenceException, they also did not update the property to BSON null as you might have expected (passing C# null to SetWrapped turned the SetWrapped into a no-op in earlier versions).
The basic rules for C# null handling are clear:
C# null is not a valid BsonValue, use BsonNull.Value instead
C# null is valid for POCOs, and will probably be serialized as a BSON null (although technically a serializer for a POCO could choose a different representation)