| bio | website | |
|---|---|---|
| location | ||
| age | ||
| visits | member for | 4 months |
| seen | 19 hours ago | |
| stats | profile views | 0 |
SQL Server developer taking on SharePoint etc.
|
May 22 |
answered | Login prompt in Document Library |
|
May 3 |
answered | Site collection locked & stucked in read only mode |
|
Mar 25 |
accepted | Can we avoid clunky hiding of WebParts? |
|
Mar 25 |
comment |
Can we avoid clunky hiding of WebParts? As suspected, it's awkward in this case because no matter if you hide first using Designer (not that you can very easily in SP2013 now) or Code, it has to be reset every user, so the code still runs. Best solution (apart from Audiences and possibly SPSecurityTrimmedControl which is also a little awkward) is as per Ali below to bypass the CreateChildControls in SP2010 or InitializeControl in SP2013. +1 for your suggestions and conf of behaviour Daniel. |
|
Mar 25 |
comment |
Can we avoid clunky hiding of WebParts? protected override void OnInit(EventArgs e) { if ( (!SPContext.Current.Web.CurrentUser.IsSiteAdmin) && HelperFunctions.IsUserType("Approver", SPContext.Current.Web.CurrentUser)) { base.OnInit(e); InitializeControl(); } } |
|
Mar 25 |
comment |
Can we avoid clunky hiding of WebParts? Thanks for this Ali - you're right!! I gave up on that idea when it fell over bypassing itself and MS advisory services didn't seem keen, but tried it properly and it does cleanly bypass the object creation without error in it's own control. Much cleaner and faster indeed, thanks for pushing it! |
|
Mar 22 |
comment |
Can we avoid clunky hiding of WebParts? did that before - so you're saying that if you set them hidden there first rather than depend on my code, they will never actually load their own code? I'll give it a shot, but in my experience the Designer setting is irrelevant because once the code hides them, they're hidden in future anyway (exactly the same as if hidden by the Designer). But if hiding them does stop any running of their code, it's not as bad as I thought (so home page running like a lame dog for some other reason - it always shows the 2013 "working on it" twice too!). Will test with debug trace on monday! |
|
Mar 22 |
comment |
Can we avoid clunky hiding of WebParts? Thanks for conf Daniel - am doing your 2 and 3 fine but just want to not load the webpart rather than "load and hide". Clients want to UAT the basics before committing cash for functions, but this basic grind is killing it. So can you load WebParts programmatically instead of inserting them onto page? Is that what you mean by 1, as I'm not sure how to do that and if it will truly avoid loading them. |
|
Mar 22 |
asked | Can we avoid clunky hiding of WebParts? |
|
Feb 13 |
answered | How to fix “A SharePoint server is not installed on this computer” |
|
Feb 11 |
accepted | Document Library - Content Type selection ignored! |
|
Feb 7 |
answered | Document Library - Content Type selection ignored! |
|
Feb 6 |
revised |
Document Library - Content Type selection ignored! added 382 characters in body |
|
Feb 6 |
asked | Document Library - Content Type selection ignored! |
|
Feb 6 |
awarded | Scholar |
|
Feb 6 |
awarded | Supporter |
|
Feb 6 |
accepted | Can clients on Office 2010 Pro use SP2013 to edit in browser? |
|
Feb 6 |
comment |
Can clients on Office 2010 Pro use SP2013 to edit in browser? Thanks John, and yes - good reality check, it sounds obvious and your answer to the title question is clearly “no” (which further licencing enquiries do confirm) although really wanted to know what actually happens under the circumstance stated? SP2010 with Office 2003 clients under Forms Based Auth gave them an ugly blank login page to confuse them. Does SP2013 allow viewing (or not) and lock editing, or tell them they are not licenced etc? Any further clarification of user behaviour appreciated. |
|
Feb 5 |
revised |
Can clients on Office 2010 Pro use SP2013 to edit in browser? include Volume License as well as Professional Plus for Office 2010 - a common scenario |
|
Feb 5 |
awarded | Student |