I am building a visual web part which has a number of user-configurable properties. The web part will display news items and, optionally, automatically switch to the next item after a defined pause.
The problem I'm having is that the user control part has a timer which fires events. These events reenter the user control (without going through the web part) and I see that when this happens the user control is in an unitialised state - i.e. the custom properties of the web part have not been applied. This causes the control to behave in it's default manner.
What am I doing wrong?
When you set property in your webPart, you need to bubble it down to the User control.
See creating custom properties for visual webparts:
http://patricklamber.blogspot.com/2010/05/how-do-i-create-custom-properties-in.html
Related
I'm using VB.NET 4.7.2
I have a multi-form application and I'm coding the "Window" menu on top to show open forms so the user can easily switch (now that Win11 has forced combining applications on the taskbar).
I need each open form to be able to handle the FormOpening and Load events generated by other forms. My current solution is to handle those events locally in each form, which then triggers a custom global event that any other form can handle.
But that's a little tedious - is it possible for one form to handle another form's closing or opening without this workaround?
You could subclass a standard form to do all the scut work of registering with the shared global and hooking other forms events. You then just need to change the forms header to point at the subclasses type and off you go.
new to .net coming from vba decided to rewrite a management app using vb.net and SQL Server.
Started writing the base library for my application.
I created custom controls to use in my application that would expose a Zoom function, background color for the current active control a .modified property similar to the one available in textbox and some extra other properties (SQLTableName, SQLColumnName, ...) to enable iterating through a container (form) for modified controls and Update/Insert into a SQL table via a SQLProcessClass.
Concurrently I'd like to also implement a simple undo functionality.
My first idea was to add a PrevValue variable set in the OnEnter event if the Modified property is False, exposing an OldValue property and an Undo method in the custom controls.
However I found that the TextBoxBaseClass already exposes an Undo method and that there is an UndoEngineClass available.
Unfortunately the vs helpfile does not give examples of how to use / implement that class.
Could someone explain the usage of the UndoEngine class non-textbox controls and if it is advisable to use it or rather write my own (as I first intended to do - I also found some interesting articles about undo/redo classes) but why reinvent the wheel in case .net already provides a class for it.
thks
I have a visual web part (sandboxed) that visualize a form for adding sub-sites. When a sub-site is added its added in the navigation and in a DropDownlist (for delete purpose...).
My problem is that after post-back everything works fine, except i have to manually reload the page to see the new changes (both nav. and dropdownlist). Note that neither Response.Redirect or UpdatePanel will work i a sandboxed-solution.
Anyone got a solution to this problem?
When you perform a postback, your browser submits the contents of all web controls to the server. The server is stateless in this sense; the state of the control is actually stored in your browser. I would say your problem occurs because the web controls are not populated from SharePoint object model. Instead, the server uses the data received as the postback. Alternatively, the population might even happen, but the postback data will overwrite the contents of controls.
The solution is to refresh control data after the controls have been populated from the postback data. You could do this, for example, in the method OnPreRender. When OnPreRender is called, all the postback data has already been processed.
Try to add the following code in your webpart class.
protected override void OnPreRender(EventArgs args)
{
if (this.Page.IsPostBack)
{
// Repopulate controls here
}
}
The problem of this is, of course, that repopulation will kill the previous (postback) state of the controls. So, if you want to preserve the current value of a control (such as a dropdown selection), you must save it before repopulation and restore it manually.
To learn more about the page lifecycle in ASP.NET, see ASP.NET Page Life Cycle Overview.
I am using SharePoint Foundation (Sharepoint 2010) to develop a workflow in Visual Studio with an ASP.NET Workflow Initiation Form.
I use this form to set some properties on the share point list item on which the workflow instance is being started. Sometimes I get an Error message in the brwoser window, something like:
Error
Failed%20to%20Start%20Workflow
Troubleshoot issues with Microsoft SharePoint Foundation.
Correlation ID: 0b8e0b67-f824-4aa5-8316-424ada134f8d
Date and Time: 6/25/2010 10:59:17 AM
Go back to site
This behaviour seems intermittent. What's going on?
The problem is that the SharePoint workflow initiation form caches the workflow List Item on PageLoad, and when you make changes to the item between the page load and calling HandleStartWorkflow (i.e. clicking on the Start Workflow button), SharePoint freaks out that the item that you're talking about is different (the cached item) to the item that exists in Share Point (which incorporates the changes you've just made).
The general steps to reproduce the problem are:
Start the workflow so that the initiation form shows.
Change some property on the WorkflowProperties.Item
Call WorkflowProperties.Item.Update to save the changes to SharePoint
Call HandleStartWorkflow.
You will get the error.
The error may seem intermittent if some of the time the change to the workflow item properties is made in a separate page load 'session' to the session that the Start Workflow button is clicked. For example, if you PostBack some form data and then click the Start workflow button then everything works, because the PostBack happened and then the page was loaded.
But if you use an ASP TextBox OnTextChanged event, change the text and then click the Start Workflow button, the OnChanged event is fired AFTER the page is loaded with the old data, the data is changed to the new data and the workflow is started before the item data is re-loaded from SharePoint.
The fix is easy: Reload the workflow item data JUST before starting the workflow. This will cause your cached workflow item and the sharepoint version of the item to be the same, and share point will be happy.
In the "Workflow Initiation Code" region, change:
Private Sub StartListWorkflow()
Dim association As SPWorkflowAssociation = workflowList.WorkflowAssociations.Item(New Guid(associationGuid))
Web.Site.WorkflowManager.StartWorkflow(workflowListItem, association, GetInitiationData)
SPUtility.Redirect(workflowList.DefaultViewUrl, SPRedirectFlags.UseSource, System.Web.HttpContext.Current)
End Sub
to
Private Sub StartListWorkflow()
'Re-initialize the workflow parameters, particularly the workflowListItem, in case it has been changed since page load.'
InitializeParams()
Dim association As SPWorkflowAssociation = workflowList.WorkflowAssociations.Item(New Guid(associationGuid))
Web.Site.WorkflowManager.StartWorkflow(workflowListItem, association, GetInitiationData)
SPUtility.Redirect(workflowList.DefaultViewUrl, SPRedirectFlags.UseSource, System.Web.HttpContext.Current)
End Sub
And everything should start working again.
The same message you will get if you try to start workflow (through the custom init form) which is already running on the item. Solution here would be to check the state of the workflow on the item.
We have a question regarding VB.Net 2008.
We are used control array in vb.net and third party timer controls.
When handle received from external application to timer control event procedure,
after this form becomes blank and controls disappear.
What we have to do to persist the controls.
You asked what you have to do to persist the controls. It's not clear whether you mean winforms or webforms, but I can answer for both possibilities:
If it's the former, you have it backwards. The default behavior of all controls is that they are "persisted" until you tell them otherwise. If anything disappears, it's because you have code somewhere that tells it to. That's where you need to start looking.
If it's webforms/ASP.Net, the problem is that you don't understand the page lifecycle. Everything that raises server events, including your third party timer controls, causes a post back. That's how events work - the browser posts the form back to the same url in such a way that the server knows to call a your event code at the right time. The thing here is that as far your server is concerned, it's still just a new http request, and that means you're working with a brand new instance of your page class every time this happens. If you've previously added some controls to your page, it doesn't matter. That was an old instance that was discarded and probably disposed by the time the page was visible in the user's browser. If you want to keep those controls, you need to make sure you add them to the page on every postback.