I have a problem using CAB Framework. I created some GUI User control interfaces and put them on my screen, that works fine. However, I would like to save my data between the different user controls. I made some DataContracts using WCF and I put the data I need in the DataContract and put those in properties so they're accessible from the WorkItem. Now I used the following function in the WorkItem to process the data:
protected override void OnWorkItemSmartPartChanged(object sender, EventArgs e)
{
MessageBox.Show(_testWorkItemControlAdres.AdresContract.Gemeente);
}
When I change between user controls, I want to see if it can succesfully access the data. However, when I switch between the wizard steps (the user controls) it never triggers the event. Do I need to add this event somewhere else or not?
Did you actually link the event to the WorkItem?
Workspace.SmartPartActivated += new EventHandler(OnWorkItemSmartPartChanged);
Cheers
Related
When you register your app as a file-save picker, you get a FileSavePickerActivatedEventArgs in your App.xaml.cs:
protected override void OnFileSavePickerActivated(FileSavePickerActivatedEventArgs e)
{
var filter = e.FileSavePickerUI.AllowedFileTypes; // This is IReadOnlyList<string>
}
When the user selects a different set of file-types:
How will I get the notification that the collection changed? FileSavePickerUI.AllowedFileTypes is not observable. Is there a trick?
#MethodMan, in Windows Store Apps you can register your app to be a FileSavePicker, which allows it to show up as an option when other apps want to "Save as...". The UI that contains your app is outside your control, like the drop down for "Save as type" (look at photo above). This drop down contains the values for FileSavePickerUI.AllowedFileTypes. When the user changes this selection, I need to get a notification. Except... I can't. I can't seem to find any way to observe this change.
Looks like there's a bug in Windows 10 as of (Oct 2015) where the FileNameChanged event does not fire when the type is changed. This only seems to work in Windows 8.
The FileNameChanged event is documented as being raised whenever the file type changes.
I just started breaking up my GUI application into UserControls. I have a TabControl with a bunch of TagePages. Obviously my MainForm.cs file was filled up with tons of events and controls etc and it got very messy quick.
So a previous question gained me the insight of how to create a UserControl. I intend on creating a UserControl for each TabPage and I was wondering how I can interact with Components on the main form or other UserControls.
Here is an example of a TabPage that I have made using a UserControl, which needs to Enable or Disable a button depending which TabPage is currently selected. Is this proper usage or is there a better way?
public partial class TabDetails : UserControl
{
private RequestForm fRequestForm;
public TabDetails()
{
InitializeComponent();
}
public void CustomInitialization(RequestForm pRequestForm)
{
fRequestForm = pRequestForm;
pRequestForm.TabControl_Main.SelectedIndexChanged += SelectedTabIndexChanged;
}
private void SelectedTabIndexChanged(object pSender, EventArgs pEvents)
{
fRequestForm.Button_SubmitRequest.Enabled = fRequestForm.TabControl_Main.SelectedTab != fRequestForm.Tab_Details;
}
}
In the MainForm.cs constructor I call:
this.tab_Details1.CustomInitialization(this);
This doesn't look like a good use of a user control. The user control should not decide how things in the form should behave when something is changed in the user control. A user control should be unaware of its container and should operate in any container.
The user control should notify the form that something has changed without telling what's the internal implementation and the form should decide what to do.
Example:
A user control named "NameUserControl" consists of TitleComboBox, FirstNameTextBox and LastNameTextBox. The user control wants to notify when one of the values has changed.
Wrong Way:
Create events:
TitleComboBox - SelectedIndexChanged.
FirstNameTextBox, LastNameTextBox - TextChanged.
The problems here:
You expose the internal controls behavior. What will happen if you want to change the TitleComboBox to TextBox? You'll have to change the event name and implementation.
You expose the fact that you use exactly 3 different controls. What will happen if you want to use the same text box for first and last name? You'll have to delete one event and change the name of the other.
Good Way:
Create only a single event: NameChanged and expose 1 property of FullName or three different properties for the values.
Either way the form subscribe to the event and decide what to do next.
Another thing to think about: the more you add more functionality to your user control, you either make it less reusable or you make its code more complex. For example, if you add validation inside the user control, you'll find one day that you need it without validation, so you'll add a property "bool ValidateData" or it will be so complicated that you'll need to build another control. One way to solve that is to build very small user controls, but combine them in one or more bigger user controls that fit all your current needs.
I'm developing a tool which shows data from a database in a hierarchical manner. As there are additional data for each item I'm using a TreeListView control to display them in additional columns. The number of columns is determined by user input.
The custom control that I'm using is Ricciolos TreeListView:
http://windowsclient.net/blogs/ricciolocristian/archive/2008/03/22/a-complete-wpf-treelistview-control.aspx
My problem now is, that I need to catch the ColumnHeaderClick event to apply a sorting logic. I already interviewed auntie Google, but no results.
Maybe somene here knows where to find such an event and how to determine which column header has been clicked.
Thanks
You would need to add a handler for the GridViewColumnHeader.Click event. This post describes how to do it for the ListView, which uses the same underlying controls. This code was adapted from that link:
myTreeListView.AddHandler(GridViewColumnHeader.ClickEvent, new RoutedEventHandler(this.OnGridViewColumnHeaderClicked));
private void OnGridViewColumnHeaderClicked(object sender, RoutedEventArgs e) {
MessageBox.Show("testing");
}
Alternatively, you can attach a handler via XAML like so:
<my:TreeListView GridViewColumnHeader.Click="OnGridViewColumnHeaderClicked" />
The e.OriginalSource will include the GridViewColumnHeader, and e.Source/sender would be the TreeListView.
I'm building an application using C#/WCF. There will be a main form project is essentially the thing that connects all the other projects (DLLs) and the DLLs are not aware or allowed to reference each other. However in one DLL, say the patient dll, there is a form with a button and when that button is clicked it needs to open a form in a different dll say the rx dll but the two DLL's can't reference each other they are only connected via the main form.
So I was wondering if it's possible to accomplish a task like that and if so how to go about it. I would prefer not to use a message queue or send message if possible.
Thanks for any advice or help.
You can link the forms with an event:
Add this to the form with the button:
public event Action OpenOtherFormClick;
button_Click (object sender, EventArgs e) //Link to the button's Click event...
{
if (OpenOtherFormClick != null) { OpenOtherFormClick()}
}
Add this to the main project:
instanceOfFormWithButton.OpenOtherFormClick += () =>
{
//Open other form, e.g.
new OtherForm().Show();
//or
new OtherForm().ShowDialog();
//or, with factory class:
FormFactory.ShowOtherForm();
};
alternatively:
instanceOfFormWithButton.OpenOtherFormClick += FormFactory.ShowOtherForm;
The factory has the advantage that you can restrict certain forms to a single instance, for example to show a detail form only once and only focus it if it's already open.
I am not sure if I truly understand your question, but you might take a look at MEF. However you can use WCF for interprocess communication (net.pipe), it's not a good practice.
I was wondering about some best practices for data binding in web forms.
For example we have a control:
public partial class MyUserControl : UserControl
{
public override void DataBind()
{
//#1
base.DataBind();
//#2
}
}
If we wanted that control to bind its data automatically we would do something like this:
protected void Page_Load(object sender, EventArgs e)
{
if (!this.IsPostBack)
{
this.DataBind();
}
}
In the first section of code if we do our data binding before the call to base.DataBind() (#1) then that means that, if for example we databind a ListView, we don't have to call ListView.DataBind() because when we call base.DataBind() on our control it recursively calls DataBind on all child controls. Also, we won't have access to any of the properties of the control that were assigned to it using the data binding code blocks <%# %>
If we do our binding on our controls after base.DataBind() (#2) then this means that DataBind is called on these controls twice. Once when base.DataBind() is called, and the second time when we are forced to call control.DataBind().
Does anyone know of some sort of pattern I can follow here that I don't know about?
Am I making any sense here?
What am I doing wrong?
EDIT:
Looking at this page:
http://msdn.microsoft.com/en-us/library/w5e5992d.aspx
Use this method to bind data from a
source to a server control. This
method is commonly used after
retrieving a data set through a
database query. The method is
primarily used by control developers;
most controls perform data binding
automatically.
It appears that best practice is to bind controls data automatically. Databinding is for when we explicitly set a data source.
I've encountered problems previously, when pages become complex and you are relying on user controls binding their own data in the page load event. This has resulted in some long debugging sessions, as you can't be guaranteed exactly when this page load event in the control will fire.
Now, that said, these pages weren't too well designed, and we shouldn't have run into this problem, but I prefer to stick with the explicit and have my page tell the child controls when to do their thing - you may wish to avoid calling base.DataBind and do it explicitly instead - you may also wish to not override the DataBind method in this way and instead call the method on your control by another name.