|
What does Serialize and MarshalByRef do ? What is the functionality ?
|
|
|
|
|
|
Here's my scenario:
I have a piece of UI that accepts that takes a value (happens to be a property on a custom object) in an edit control. When the user commits the change, the form controls are disabled and the value is applied to an underlying object, which takes a couple of seconds. When the underlying object completes the assignment of the value it fires an event indicating that the change is complete. When the event is received, the UI is enabled and the user can proceed. Should be a piece of cake.
Note: Perhaps the user experience could be designed a little better, but that is a separate issue, for now it is what it is.
After spending a couple of weeks messing around with XAML, I can't see how this can be done in XAML by a non-coding (UI person), it seems like I have to implement handlers in code behind or start building my own custom controls.
Explanation:
1) The event object is not of type Routed Event.
2) If the event was of type RoutedEventArgs, I would have to lose information that is passed in the existing event.
3) The underlying object is not a UIElement, so it can't raise that event anyway, have to subclass and create a new custom control.
4) If I implement a data binding object to catch the custom event, I have no way to "catch" the custom event or even the standard PropertyChanged notification in a useful way in XAML.
5) If I try to implement a trigger on the PropertyChange notification, I can only do so in style that cannot operate on child or parent objects (thus the form can't use a trigger and setter on propeties of the textbox)
6) Event triggers can only operate on Routed Events defined for the object in question - custom control again
7) Event triggers can only operate on the control raising the event.
8) Event triggers call handlers which are implemented in code (behind or inline).
9) yada, yada, yada
In summary, my form cannot respond to events or property changes in child objects, only the controls themselves can.
Additionally, controls only respond to predefined events, requiring sub-classing for additonal events/properties.
Finally the only events at my disposal are of type Routed Events so a limited amount of information can be provided.
Granted, today I do not have any kind of Markup language for my UI folks to use that can readily transfer to Visual Studio, but even with XAML, a programmer is still required to implement the code behind and wire the layout together. The idea that UI folks can develop applications in XAML while coders just work on DataSources and Validation objects seems to be a myth, or at least a Nirvana that NET 3.0 doesn't acheive.
Am I missing something. Seems like I am learning a whole new language and shifting to a new development paradigm just so I can import UI layout from a designer tool.
|
|
|
|
|
I feel your pain. I, too, am torturing myself with the hazy and poorly documented world of WPF. 
IMO, the behavior you described (disabling the UI until a custom event fires) sounds like something that should not be in the XAML. From my experience with WPF so far, it seems that a layout and appearance settings should live in XAML, but any specialized behavior should be in the code-behind. Francois, the turtlenecked artiste, should not have to see the implementational details of how an app behaves.
That's just my opinion, though.
Josh
|
|
|
|
|
Agreed, I don't want Francois the artiste to know anything about my application, but it would be nice if Alex the useability/design guy were able to do build out working prototypes to show to customers.
I guess I bought into the myth that non-coders would be able to do app. development, but it doesn't seem the case unless they're doing real fluffy stuff that doesn't interact with any of our code. Unfortunately my boss bought into that myth too.
I think there is a lot to like about WPF, its just XAML that I'm having trouble with. XAML does suggest an ability to react to property changes and events, and that you should be able to write an application with it, it just doesn't really cut it for rich-client development IMHO. I'm sure that people at insurance companies writing input screens that just collect data and drop it in a DB will be quite happy with it, especially with the binding and validation hooks.
|
|
|
|
|
nicknotyet wrote: I'm sure that people at insurance companies writing input screens that just collect data and drop it in a DB will be quite happy with it, especially with the binding and validation hooks.
Having worked at an insurance company, I can tell you it's not that easy. Their applications are just as demanding as anyone else's.
Logifusion[^]
|
|
|
|
|
Yes, that was kind of a gross generalization, sorry about that.
You got the idea though.
|
|
|
|
|
My take on the XAML/code split is a little different than yours. What I filtered out of the MS advertising mumbo-jumbo is that application devs and graphic designers can work separately, most of the time. Instead of having a GD come up with a visual theme/layout for the app and then say to the dev, "Make it look like this.", the dev can give the GD a layout and say "Make this look good."
I never picked up a notion of MS saying "With XAML, anyone can create enterprise apps!" That's been tried, always with the same obvious outcome. To me, their message (to the business world) has been "With XAML, you won't depend on your aesthetically challenged developers to make things look good."
Maybe we've been reading different MS ads, though...
Cheers,
Josh
|
|
|
|
|
Like I said, I bought into a myth (or rather, it was imposed upon me). Your take is consistent with the product, so I believe you and confirms my impression of XAML.
|
|
|
|
|
If you have the time (yeah right), you might want to do an article search on CP for MyXAML. It's something Marc Clifton is involved with very heavily. It's similar to Microsoft's idea, just from a different approach.
Logifusion[^]
|
|
|
|
|
Is the Grid-tag just good to define the layout/alignment of controls, or can be used as a true grid control?
Does it allow scrolling with a fixed header? Can I navigate through the cells with the arrow keys?
If I want an array of 20x20 edit boxes, do I have to define each edit box or can I use the ColumnDefinition/RowDefinition to get a column/row of controls?
Does the grid itself has any events to notify the parent that cell x,y has changed, is not beeing edit etc.?
Links with information about the grid would be great too.
Thanks Andre
|
|
|
|
|
|
I found MS to be pretty responsive, not as collaborative or quick as CP.
http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=119&SiteID=1
|
|
|
|
|
Thanks, from what I've read so far the grid is not a true grid control, although Microsoft calls it so. It just defines the layout of the child controls like a table.
Dustin Metzgar wrote: You might not get much help this early in the game.
Isn't Avalon under development since 5 years? Also after all the hype Microsoft already made around WinFX/WPF I'd expected a little bit more than a set of common controls that we already had on Win95.
I'll guess we have to wait for 3rd party controls again 
|
|
|
|
|
Actually, I just read in the forum posted above that they don't have a date/time picker. I guess I can understand why it's lacking in the features department because the backend of it is the most important. They're now pushing the graphics processing off to the video card, which is a big step in the right direction IMO. You might not have a date picker, but you can place 3D objects in your windows. 
Don't worry. In a couple more years, we might actually have a workable system.
Logifusion[^]
|
|
|
|
|
Dustin Metzgar wrote: Don't worry. In a couple more years, we might actually have a workable system.
I like the idea of using markup to declare the UI, but so far I'm not impressed at all. The designer always ends up with invalid XAML and if I get a WPF app running it eats a lot of memory just for an other set of controls which we already have in Windows Forms and the Windows common controls 
And the Grid-tag is basically nothing else than the Table-tag, just that the child controls can be layered
Is it possible to create custom controls using XAML? Can I invent my own tags and put it into XAML?
|
|
|
|
|
ABuenger wrote: Is it possible to create custom controls using XAML? Can I invent my own tags and put it into XAML?
Yes, you can definitely write your own controls: http://windowssdk.msdn.microsoft.com/en-us/ms745025(VS.80).aspx[^]
I'm not sure about writing your own tags though. There's an xsd out there that xaml files are validated against. I imagine if they let you add your own tags, it would cause errors with the validation. It looks like the custom control they make in the article does not have its own tags.
Logifusion[^]
|
|
|
|
|
You can add your own tags into a XAML file. You need to import your class's namespace via xmlns:myNameSpace="clr-namespace:MyNameSpaceBlah" in a Window or Page tag. Then you can include your own types in XAML by writing:
<myNameSpace:MyType />
I think CP needs more .NET 3.0 space! Perhaps part of the reason that many CPians are exploring .NET 3.0 (assuming that is actually the case) is because CP hasn't launched forums for those topics yet...
Josh
-- modified at 13:16 Wednesday 21st June, 2006
|
|
|
|
|
-an other set of controls which we already have in Windows Forms and the Windows common controls
From the perspective of someone accustomed to coding up UI and attaching it to business logic, it kinda feels like a step backwards. I can see it as win for an organization that wants to use differently skilled (often less expensive) people with graphic design and/or HTML background to focus on UI layout and wiring in the presenation layer (validation, data binding, etc.) objects.
Alas, it forces one into a rather strict (not extensible) UI/code model that I personal am not enjoying yet. I have to find a way take an event driven back-end and find some way to mate to a property oriented front end (not pretty thus far) so that our useability folks can do app. development without coding. I'm hoping the story will get better as I understand it more.
|
|
|
|
|
No, the Grid in WPF is strictly for layout purposes. It not a data container, like DataGridView. If you are looking for a data grid control, Infragistics has their DataPresenter, which you can request from them.
Cheers,
Josh
|
|
|
|
|
Have some architectural issues I need to hash out.
|
|
|
|
|
There aren't any WPF (or .NET 3.0) forums yet, but there have been murmurs here and there requesting them. I think that right here in the .NET Framework forum is a good place to post such questions, especially since they changed the name to .NET Framework 3.0 
Josh
-- modified at 11:06 Wednesday 21st June, 2006
|
|
|
|
|
Hello,
I want to share datas managed in a DLL that is called by 2 different applications.
Someone said me sometimes a DLL with singleton can have 2 instances.
An other solutions exists ?
thanks
Freg
|
|
|
|
|
When a DLL is used by a process, a "fresh copy" of it is loaded into that processes address space. The singleton instance of a class in one process is a separate entity from the singleton instance in another process.
What you could do is use .NET remoting to host a singleton instance of your class. When either of your apps needs to access that truly unique instance, it would request it from the remoting service. If you need more info about remoting and singleton activation, CP has some great articles on that subject.
Josh
|
|
|
|
|
Are these applications running on the same machine or on a network?
Best,
Jun
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
