|
Mika Wendelius wrote: Not sure if I understood your problem correctly
Me either. However, I suspect he is looking for a two word book report on War and Piece. 
led mike
|
|
|
|
|
That's an excellent interpretation, why didn't I figure it out 
The need to optimize rises from a bad design.
My articles[ ^]
|
|
|
|
|
Sorry for confusing you guys 
As you must have guessed by now, I m new to the interoperability stuff  . The questions on my mind are: does compiling existing C++ code with /CLR switch automatically emit MSIL for all the unmanaged code written? Will we get to keep the existing C++ code same across Unix and .Net(Windows), just like the way it is now (just needing recompilation)? If yes, is there any performance loss to it?
I know there is a chance that I am still not clear, but at least I added one more question to what I already asked. Perhaps you can have a clue where I m leading/misleading myself.
|
|
|
|
|
Btw, Mika, Mono seems a good option. But the API + func dll we have run in IBM AIX, SCO UnixWare, HP HP-UX, Sun Solaris apart from Linux. I dont find any mention of these on the Mono website.
|
|
|
|
|
|
|
i have one questions about Builder Pattern ..why we need product class where director class construct the component of product and when i want to produce any product i will implement IBuilder interface and write the behavior of each component and pass the concrete Builder to director without need the product and i will produce also different representation , plz give me the benefit of product class and real world example if u can ?
Discover Other ....
http://www.islamHouse.com
|
|
|
|
|
Builder pattern consists of 4 parts:
1. Builder-This is an abstract class
2. ConcreteBuilder
3. Director-This is the site where the construction occurs by calling the ConcreteBuilder
4. Product-This is the thing being built
public class Demo
{
public static void main(String args[])
{
Builder b = new ConcreteBuilder1();
Director d = new Director();
d.construct(b); // We tell director to construct a product using b as the builder and director
// will call the appropriate methods on b. We do not need to know how the director
// will do this, we assume the director knows this.
Product aProduct = b.GetProduct(); // Now we ask b to give us the built product
b = new ConcreteBuilder2();
d = new Director();
d.construct(b);
Product anotherProduct = b.GetProduct());
}
}
Therefore, you need the product class because after all you are after the built product at the end.
It is like going to a construction site and taking a builder with you. You ask the person in charge at the construction site (Director) to construct a house for you using the builder you introduced to the person in charge. The person in charge should know the sequence and what parts are needed to build a house but does not know how to build it. He simply asks the builder to build the parts. The builder now has a complete house. To see the completed house, you ask the builder for the house. I personally think we should ask the Director for the finished product as well and the director should ask the appropriate builder, but for some reason that is not the case.
|
|
|
|
|
Ok so I am looking into the 3.5 workflow services and developing support for some application form workflows. So far I have only come across fairly simplistic tutorials, the best being on channel9. I can understand that, there seems to be an astonishing level of complexity involved in putting one of these together.
My intentions are to have ASPX forms deployed via sharepoint services. The forms are to be served by a workflow service and data stored on SQL Server.
Basically a form to be filled, various levels of sign off with a reject or cancel option where reject allows the originator to resubmit. There may be substantial delays during the workflow. From my investigations so far it seems a state machine workflow will be the best solution but a sequential workflow may meet most requirements.
Issues are
Which workflow to use?
It seems all interaction needs to go through a send/receive event and therefore serialised datasets will be passed through the service.
Should the supporting data for the form (tables for dropdowns) also pass through the workflow service or should I seperate the static data from the workflow data?
So far the tutorials seem to assume the data is discarded once the workflow is completed (stored as xml during the workflow) but I would like to retain the information for analysis. Should the xml data be parsed out to tables etc for easier query access.
Am I missing anything from the following list
Persistence data store - SQL Server
Form information and static data - SQL Server
Logic layer to interact with the form information database (Program.cs)
Contract/Interface per application form
Workflow Service
Client (ASPX)
Also if there is a tutorial/article out there related to this type of workflow I would appreciate a link.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
A common task we always have to accomplish is to allow users to edit objects from the UI. For example, lets say I have an employee class with the regular properties. The UI will have textboxes and other controls to display the properties. A user can select an employee by name from a listbox, treeview, combobox or whatever (not important to this question) and the form will display the employee. These are different approaches I have been taking to display the employee and I was wondering which is a better approach or if you can recommend one:
1. Create a property within the employeeForm called Employee and when it is set the form will call its private ReLoad() method and display the employee.
2. Create a property as mentioned in 1, but do not ReLoad in the setter, instead make the ReLoad method public and clients should call the ReLoad method after setting the employee.
3. Forget the property altogether and just have a method called Load(Employee emp). This is basically a method which takes employee as a parameter and then displays it.
What do you think?
|
|
|
|
|
|
I am very familiar with MVC and use it all the time.
|
|
|
|
|
CodingYoshi wrote: I am very familiar with MVC and use it all the time.
Really? How are any of the options you posted in your first post, part of the MVC design? I don't see it.
led mike
|
|
|
|
|
led mike wrote: How are any of the options you posted in your first post, part of the MVC design?
I never said my options had anything to do with MVC pattern. I use MVC pattern but in this case my question is not about MVC. My question is closely related to the observer pattern. You have an object of a class which is being observed by the form by subscribing to its events. Now when the user selects a different object from a treeview (or whatever), this class will become the new object the form is observing and the form should display its data. But the form can only do so once the object fires the event. But the object will fire the event when its state changes so the form has to wait until the user changes the state of the object. So now we are stuck because this is what has been happening so far:
First an object was selected from the treeview. The object is sent to the form. The form subscribes to its events. The events are not fired so how do we display it?
The solution I came up with is to trigger the event through a public method--just like we can trigger events in .NET by calling OnPaint. Now the form can display the data.
So I think the answer to my question is to set the property and send a reference of the object to the form. Afterwards, force the objects event by triggering it through a public method. But I am still not sure if this a good solution.
|
|
|
|
|
hi,
I've finished all the base code to my App. Tested it and everything, now I
need to make a UI.
Its not going to be overly complex but it could get complex later on, so I
want to design it well.
I want a proper way to enable/disable UI but later being able to change
maybe the real control, so far i've come up with.
interface IMainForm
{
IUIController GetUIController(string name);
}
interface IUIController
{
bool Enabled
{ get;set;}
}
The default implementation would be:
class DefUIController : IUIController
{
DefUIController(Control cntrl);
{
}
}
And then in the main form I could search for the control and create a new
UIController and return it, like this:
IUIController GetUIController(string name)
{
foreach(Control crt in this.Controls)
{
if(crt.Name== name)
{
return DefUIController(crt);
}
return null;
}
}
I would need to change the state of a control from a sub UserControl which has a reference via a property to IMainForm.
Like, if the selected Customer in the CustomerGridView UserControl doesn't have a bill yet, _within_ the usercontrol i could do this:
IUIController ui = _mainform.GetUIController("mnuPrintBill");
ui.Enabled = false;
Is this design good enough or is there a method out there, I don't need
something complex like CAB or something, its not such a big app.
Thanks so much.
Gideon
modified on Thursday, November 13, 2008 12:07 AM
|
|
|
|
|
Gideon - when I wanted automatic control of UI elements, I knocked up this[^] sample. It's a trivial example, but easily extendable into something more powerful (we did).
|
|
|
|
|
Hello,
I am not sure if it is a good suggestion or not as I have done it myself but you can use Command pattern for your application. You can use databinding to bind several ui controls to one ICommand object and then changing enabled/visible property of the ICommand will automatically enable/disable, hide/show by the magic of databinding 
|
|
|
|
|
hi,
Thanks you guys, but un fortunately UI needs to be disabled based on more complicated situations. Like User permissions, and things like say if its a customer's last day of stay, stuff like that.
I will have a customer grid, so if a certain customer is on his last day, in the user control I would do this:
if(selectedReservation.EndDate == DateTime.Today)<br />
{<br />
} else {<br />
}<br />
I can't put all possibilities into an Enum, and I think databinding would be a little convoluted since some situations are more complex.
Is my design stupid? that I'm looping through the controls?
Thanks so much.
|
|
|
|
|
giddy_guitarist wrote: Is my design stupid? that I'm looping through the controls?
I don't think there is much else to do really. It just ties your code really tight to your business rules in the UI.
You may want to take a hybrid look and do both. Look at what can be done via a form based state machine then augment that with some business rule specific stuff.
|
|
|
|
|
Hi
As Giorgi mentioned, the command pattern allows you the control of enabling/disabling.
You will find an example for WPF here WPF Command-Pattern Applied[^]
Here you will find an example for WinForms[^].
Regards,
Jani
|
|
|
|
|
I would split the UI management into 2 distinct types, 1 based on permissions and user group membership and 2 state of the data. Either way it is custom coding for each form.
I like the idea of binding the enabled/visible attribute.
I use a permissions table that is returned from the login with all the permissions for the logged in user. Then each form checks this table for defined controls. While I implement this in all apps it is rarely used(corporate).
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
I think using the MVC pattern is a good solution. I use it all the time. With events the whole process becomes easy.
Create an event in your business object called Validated or something, have the User Interface subscribe to this event. Within the handler put the logic for enabling/disabling control.
Find out ALL the condition which will enable and disable your control and use boolean logic like below:
nameOfButton.Enabled = customer.IsActive && customer.IsValid && someotherCondition || someotherCondition && (someotherCondition || !somotherCondition)
I like this solution because all the rules for the ability of my control are in one spot and the button will only be enabled if all conditions are satisfied.
One thing you want to stay away from is code such as nameOfButton.Enabled = true. Reason being is that somewhere another programmer, or yourself will have another similar call that disables the button. The latest call will actually decide the ability of the button. In situations like this you end up with a lot of if statements and things become very ugly soon.
|
|
|
|
|
Interesting,
I've been quiet for sometime because I was doing a little more thinking, I decided to use the MVP pattern for each UserControl(View) that I make, however what I was talking about was Enabling/Disabling a control in the MainForm from a UserControl, I would end up having a reference to the MainForm from the UserControl then, which glues the UserControl to the MainForm!
MainForm
---------------------
CustomerView(UserControl): A customer is selected, something needs to be disabled in the MainForm.
BillView(UserControl)
---------------------
But now,
It seems I will only have a MenuBar and a ToolBar on the MainForm, there will also be a TabControl and inside these TabControls will reside different views. So I just have to bother about diabling/enabling menus and toolstripitems.
Now, I thought of encapsulating the Toolbar and MenuBar and have themselves decide what needs to be enabled and disabled instead.
Like
class HmsMenuBar : MenuStrip
{
//during the OnDropDownOpening.. i can check if items should be enabled/disabled.??
}
Same thing for the ToolBar, does this sound ok?
Thanks so much
Gideon
|
|
|
|
|
UI controls, whether the main form or the User Control is just a mechanism to allow a user to interact with the underlying. What I do not understand is why you want the user control to enable/disable main forms controls: They must know about each others controls and adds to coupling which is not ideal. If you want a menu item to enable/disable based on customer's last day or whatever, then have both the main form and the user control subscribe to the customer. UserControl will do what it is supposed to do and main form will do what it is supposed to do. Now these UI elements only know about the "thing", in this case the Customer, they are displaying but not about each other.
It will be like this: Customer is loaded and obviously properties will change, then the UI Control will subscribe to an event from customer--you have to create the events based on your requirements. In this handler, the control will ask the customer for whatever it is interested in, for example, IsLastDayOfStay, if true will enable itself and false otherwise. The main form will also subscribe, and ask for something else and mold itself accordingly. You can also design it so the form does not need to ask the Customer, but the event arguments can have the information in it. For this, you would need to create a simple class to encapsulate even arguments.
The only problem is the controls are tied to your object.
If I am not understanding what you want to do, then just write in plain English with no code what it is you want to achieve and hopefully I or someone else can give you a suggestion.
|
|
|
|
|
I kinda understood what your saying better after looking at paint.net source code lol! I've been looking at a lot of programs like that for inspiration.
So the Main form code itself should decide what menus and toolbars need to be enabled/disabled by querying/using business objects itself? That would be a correct design? (Atleast thats how it is in Paint.NET)
(I'm sorry if i sound daft from time to time, I'm young and not formally computer educated!)
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
