Sometimes Network admin policies just get over the top and especially for bods like us who require to have the IE Developer Tools enabled for script debugging etc.
Firstly check whether these 2 registry settings been set
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Internet Explorer\IEDevTools
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\IEDevTools
If they have been to 1, set them to 0 to disable these disabling keys ;-)
However , it is highly likely a Network GPO policy is overriding this setting therefore the trick is if you have admin rights on your local machine. Create a local user on the desktop machine. Then assign it as an administrator locally.
Then login to the desktop eg .\user then password.
Then you should be able to open gpedit.msc from the run command.
Then check this setting below.
Computer Configuration -> Administrative templates -> Windows Components -> Internet Explorer -> Toolbars -> Turn Off Developer Tools = Set to Disable.
Restart all IE instances and the F12 developer tools under Tools menu should be activated again.
Show By Category
.NET Service
(1)
1909
(1)
ACTV
(1)
adidas
(47)
adizero
(1)
Admiral
(9)
Airness
(3)
Albania
(3)
Algeria
(3)
America Mineiro
(1)
Angola
(1)
Anta
(2)
Argentina
(2)
Armenia
(1)
Atletico Goianiense
(1)
Atletico Paranaense
(1)
Austria
(2)
Authentic fit
(1)
Auto Generate from Access
(1)
Avai FC
(1)
avoid
(2)
Bahia
(1)
Beijing Guoan
(1)
Belgium
(4)
Benin
(1)
Birmingham City
(1)
Bolivia
(1)
Boot Configuration Data missing
(1)
Bosnia
(1)
Botafogo
(2)
Botafogo SP
(1)
Botswana
(2)
Brazil
(4)
Brazilian brand
(15)
Bulgaria
(2)
Burkina Faso
(2)
Burrda
(3)
Bypass traverse checking
(1)
Cambodia
(1)
Cameroon
(4)
Ceara
(1)
CEWP
(2)
Chapecoense
(2)
Chile
(3)
China
(9)
Chinese Brand
(4)
Chongqing Lifan Dangdai
(1)
Club Deportivo Universidad Catolica
(1)
Club Universitario de Deportes
(1)
Clube de Remo
(1)
Colombia
(6)
Colombian Brand
(1)
Congo DR
(1)
Congo Rep
(1)
Copa America
(3)
Corinthians
(1)
Coritiba
(1)
Costa Rica
(2)
Cote d'Ivoire
(3)
Coventry City
(1)
Croatia
(2)
Crop IFRAME
(1)
Cruzeiro
(2)
Crystal Palace
(4)
css
(3)
Cuba
(1)
Cyprus
(1)
Czech Republic
(2)
Deleting large libraries
(2)
Denmark
(2)
design fault
(2)
Diadora
(1)
Dragao Premium
(1)
eagles
(1)
Ecuador
(3)
Ecuadorian Brand
(3)
Egypt
(1)
El Salvador
(1)
electrical
(2)
electrical problems
(2)
electrocuted
(2)
England
(3)
Errea
(3)
Espanyol
(1)
Ethiopia
(1)
Euro 16
(10)
Excel 2010
(3)
External Content Type
(1)
FBT
(3)
FC Porto
(1)
Fenerbahce
(1)
Figueirense
(1)
Finland
(1)
Fiorentina
(1)
Flamengo
(1)
Flickering
(1)
Fluminense
(1)
football
(233)
Fortuna Dusseldorf
(1)
France
(2)
futfanatics.net
(1)
Gabon
(1)
Germany
(1)
Ghana
(2)
Gogoalshop
(2)
Goias
(1)
Granada CF
(1)
Grand Sport
(2)
Greece
(2)
Green
(1)
Guangzhou Evergrande
(1)
Guinea
(1)
Guinea Bissau
(1)
Haiti
(1)
Heilongjiang Lava Spring
(1)
Honduras
(1)
Hong Kong
(1)
Hummel
(1)
Hungary
(1)
Iceland
(3)
Icone Sports
(2)
IE Developer Tools
(1)
India
(1)
Indian Brand
(1)
Internal Field Names
(1)
Italy
(2)
Jako
(1)
Jamaica
(2)
Japan
(1)
Javascript
(6)
Jersey
(126)
Jiangsu Suning FC
(1)
Joma
(5)
Kanxa
(1)
Kappa
(3)
Kelme
(4)
Kenya
(1)
kitchen extractor fan
(3)
Korea
(1)
Laos
(1)
Le Coq Sportif
(1)
leak
(2)
Legea
(1)
Levante
(1)
Li Ning
(3)
Local Security Policy
(1)
Login Problem
(1)
Lotto
(4)
Lupo
(2)
Macron
(9)
Mafro
(3)
Mali
(3)
Man Utd
(1)
Marathon Sports
(6)
Marseilles
(1)
masterpage
(1)
Meizhou Hakka
(1)
Mexico
(5)
Modena Volley
(1)
Montenegro
(1)
Morocco
(3)
Myanmar
(1)
N98
(1)
Naija
(1)
Nakal
(1)
Namibia
(1)
Napoli
(1)
Netherlands
(1)
New Balance
(2)
Newcastle United
(2)
Niger
(1)
Nigeria
(4)
Nike
(32)
Nike Brasil
(1)
Nike Brazil
(1)
Nike China
(12)
Nike South Africa
(1)
North Macedonia
(1)
Norway
(1)
O'Neills
(1)
Oldham Athletic
(1)
Olympikus
(1)
Olympique Lyonnais
(1)
Page Viewer WebPart
(1)
Panama
(2)
Para
(1)
Paraguay
(2)
Penalty
(1)
Peru
(6)
Picture Manager
(1)
Poland
(2)
Ponte Preta
(1)
Portugal
(2)
Portuguesa RJ
(1)
problem
(2)
Puma
(46)
retro
(1)
review
(111)
Romai
(2)
Romania
(1)
RT Sports
(1)
Russia
(4)
Saeta
(1)
Sampaio Correa
(1)
Santarem
(1)
Santos
(2)
Sao Paulo FC
(1)
Sao Raimundo
(1)
scam
(2)
Score Draw
(1)
Search List with Count Displayed
(1)
Senegal
(3)
Serbia
(1)
Server Hardening
(1)
SESI Sao Paulo
(1)
Shandong Luneng
(1)
Shanghai Shenhua
(1)
Shanghai SIPG
(1)
SharePoint
(61)
SharePoint Connect to SQL
(2)
SharePoint Designer
(3)
Shenzhen FC
(1)
shirt
(232)
Sierra Leone
(1)
Singaporean Brand
(2)
Six5Six
(1)
Slovakia
(2)
Slovenia
(1)
Slow right click
(1)
Sondico
(1)
South Africa
(1)
Spain
(3)
SPS Services
(2)
Spurs
(1)
SQL Server 2008
(1)
SSP User Profile behaviour
(1)
Super Bolla
(2)
Sweden
(2)
Switzerland
(2)
Taubate Funvic
(1)
Team GB
(2)
techfit
(8)
Thai Brand
(3)
Thailand
(2)
Togo
(1)
Topper
(4)
track top
(13)
Travels
(1)
Trinidad and Tobago
(1)
Tunisia
(3)
Turkiye
(1)
tyro
(1)
UAE
(1)
UB
(3)
UB Electric
(3)
Ucan
(1)
UE Llagostera
(1)
Uganda
(1)
Uhlsport
(2)
Ukraine
(1)
Umbro
(18)
Umbro Brazil
(6)
Under Armour
(3)
Upload Center
(1)
Uruguay
(1)
Vasco Da Gama
(1)
Venezuela
(1)
Vietnam
(1)
Villa Nova
(1)
Villarreal
(1)
Vitoria
(1)
volleyball
(6)
Vozao
(1)
Wales
(1)
Warrix
(1)
water
(2)
WebClient
(4)
WebDav
(5)
West Ham
(2)
Where to get buy Iceland football shirt in Reykjavik
(1)
Win 8
(2)
Windows 10
(1)
Windows Scheduled Task
(1)
wish list
(1)
Workflow
(1)
World Cup 14
(9)
World Cup 18
(5)
Wuhan Zall
(1)
Xinjiang Tianshan Leopard
(1)
Xtep
(1)
Yanbian Funde
(1)
Yemen
(1)
Zambia
(1)
Zhejiang Greentown
(2)
Zimbabwe
(1)
Monday, 23 June 2014
Monday, 16 June 2014
Space in Field Names
I think numerous people have mentioned this but it still stumped me for a while when I was trying to code a CAML query in SharePoint where I needed to get de-reference a field that had a space in it.
The field was name "A Type" and because of space or any other unsuitable characters, it will set it as such in its internal field name.
You can always find out what its internal name is by going to the List settings and columns, right click on the field hit properties and in the dialog window's look in the bottom of the Address URL property.
It will show something like this for "A Type" that is "A%5Fx0020%5FType"
Using A%5Fx0020%5FType in the JQuery code will not work as instead
%dF needs to be underscore
Therefore, it should become A_x0020_Type in the field referencing code.
eg
<viewFields> \
<ViewFields> \
<FieldRef Name='Title' /> \
<FieldRef Name='A_x0020_Type' /> \
</ViewFields> \
</viewFields> \
And when using ows to get the xml nodes returned.
$(this).attr("ows_A_x0020_Type")
The field was name "A Type" and because of space or any other unsuitable characters, it will set it as such in its internal field name.
You can always find out what its internal name is by going to the List settings and columns, right click on the field hit properties and in the dialog window's look in the bottom of the Address URL property.
It will show something like this for "A Type" that is "A%5Fx0020%5FType"
Using A%5Fx0020%5FType in the JQuery code will not work as instead
%dF needs to be underscore
Therefore, it should become A_x0020_Type in the field referencing code.
eg
<viewFields> \
<ViewFields> \
<FieldRef Name='Title' /> \
<FieldRef Name='A_x0020_Type' /> \
</ViewFields> \
</viewFields> \
And when using ows to get the xml nodes returned.
$(this).attr("ows_A_x0020_Type")
Thanks for this post to point me into the right direction.
http://abstractspaces.wordpress.com/2008/05/07/sharepoint-column-names-internal-name-mappings-for-non-alphabet/
I was scratching my head for a while.
To avoid this, never use space, semi colon or non alphanumeric characters when naming fields. Use underscore for space and this problem just gets side stepped.
Subscribe to:
Posts (Atom)