Posted by Eric Bartels
I came accross an issue when using TMG / UAG with SharePoint Workspace 2010. When connecting to a site I got the error
SharePoint Workspace was unable to interpret the SharePoint location.
Please check and ensure the location contains no typing errors.
Of course this error message is misleading. Solutions found in “the internet” like adding “remote differential compression on the server” were not applicable…
So after further tracing I found the culprit. The ULS logs (verbose mode was configured for logging) showed the exact web service calls SharePoint Workspace 2010 did with its full soap body. One call showed an url which I was pretty sure was not inside the AAM of that specific web application. Other calls always show the correct public url of that web application. Just one specific call … So I added it to the configuration and everything is working and synchronizing as expected.
If you encounter this error check your ULS logs and double check your AAM settings!
Posted by Eric Bartels
I came across this rare bug in the current development of a project. It makes heavy use of the RowEditing plugin of Extjs‘ grid. Because the Extjs environment is used within SharePoint 2010 I have to use the scoped theme to avoid “damage” to the SharePoint UI.
After inserting a record into the grid via RowEditing and pressing cancel the RowEditings’ editor window is not shown. You guess it right: only when using Internet Explorer (7, 8, 9). After testing it showed that the css itself is not the reason. So debugging the Extjs-source where the setting scopeResetCSS is evaluated…
The final result is a workaround applied via Ext.override to solve the “problem”.
if(Ext.isIE) {
Ext.AbstractComponent.override({
onRender: function(container, position) {
var me = this,
el = me.el,
styles = me.initStyles(),
renderTpl, renderData, i;
position = me.getInsertPosition(position);
if(!el) {
if(position) {
el = Ext.DomHelper.insertBefore(position, me.getElConfig(), true);
}
else {
el = Ext.DomHelper.append(container, me.getElConfig(), true);
}
}
else if(me.allowDomMove !== false) {
if(position) {
container.dom.insertBefore(el.dom, position);
} else {
container.dom.appendChild(el.dom);
}
}
if(Ext.scopeResetCSS && !me.ownerCt) {
if(el.dom == Ext.getBody().dom) {
el.parent().addCls(Ext.baseCSSPrefix + 'reset');
}
else {
if(me.$className != 'Ext.grid.RowEditor') {
me.resetEl = el.wrap({
cls: Ext.baseCSSPrefix + 'reset'
});
}
}
}
me.setUI(me.ui);
el.addCls(me.initCls());
el.setStyle(styles);
me.el = el;
me.initFrame();
renderTpl = me.initRenderTpl();
if(renderTpl) {
renderData = me.initRenderData();
renderTpl.append(me.getTargetEl(), renderData);
}
me.applyRenderSelectors();
me.rendered = true;
}
});
} |
The woraround itself is only this:
if(me.$className != 'Ext.grid.RowEditor') {
me.resetEl = el.wrap({
cls: Ext.baseCSSPrefix + 'reset'
});
} |
BTW: I “love” IE!
- January 9th
- Filed under: SharePoint-Development, Webdevelopment, bug, extjs, extjs4, grid, IE, JavaScript, override, RowEditing, scoped-theme, sencha, SharePoint, SP2010
Posted by Eric Bartels
I was trying to move the top.links block (aliased with topLinks) from the header-block to the right-block only using local.xml. Should be easy right?!
I did not found any solution using this way in the wiki or somewhere else.
Simply using unsetChild and simply put the top.links block somewhere else is not working! All default links except the Log in / Log out disappear.
So here is my solution that works. The key is using insert as action…
<?xml version="1.0" encoding="UTF-8"?>
<layout>
<default>
<reference name="header">
<remove name="top.search" />
<action method="unsetChild">
<alias>topLinks</alias>
</action>
</reference>
<reference name="right">
<action method="insert">
<blockName>top.links</blockName>
</action>
</reference>
</default>
</layout> |
Note: Its important to use the alias when defining action="unsetChild" or the block is not “moving”. Seems buggy to me …
Posted by Eric Bartels
Today I encountered the same problem as stated in a blog post by Christopher Maish. When activating the feature via powershell the associated feature receiver was not called.
Trying the suggested solution in the blog post drove me to the cause of this problem. When using stsadm I got an “access denied” error.
I did run my script via Powershell ISE within Windows Server 2008.
So the real problem is caused, again, by UAC (User Account Control). When starting the Powershell ISE with “Run as administrator” and executing the script the feature receiver is now called as expected. Even when using Enable-SPFeature!
Posted by Eric Bartels
Writing CAML-Queries is still no fun. Even with SharePoint 2010… So you often need to test your queries before they actually work.
In case you quickly want to test if your SPSiteDataQuery is correct you can use powershell to “debug” it. Just create an instance of the site-collection and target the root-web with your query-instance.
$site = Get-SPSite -Identity http://my-site-collection
$q = New-Object -typeName Microsoft.SharePoint.SPSiteDataQuery
$q.Query = "<Where><And><Eq><FieldRef Name='ContentType'/><Value Type='Text'>MyCT</Value></Eq><BeginsWith><FieldRef Name='Url'/><Value Type='URL'>/path</Value></BeginsWith></And></Where>"
$q.ViewFields = "<FieldRef Name='ID'/><FieldRef Name='ContentType'/>"
$q.Webs = "<Webs Scope='SiteCollection' />"
$site.RootWeb.GetSiteData($q) |
This is way faster than doing it in VS…