|
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
|
|
|
|
|
|
Then it looks like a typical IPC case. In theory, all IPC mechanisms may work for your purpose, but "shared memory" should be an effective solution for significant amount of data sharing. On Windows platform, it's implemented as "memory-mapped files" or MMF. An MMF is a kernel object that maps a disk file to certain memory block of your process address space so that multiple processes/DLLs can access the same data as if they were accesing its own process data.
Google "sheared memory" or "memory-mapped file" to get yourself on the track. If you need more guidance, drop a line here.
Best,
Jun
|
|
|
|
|
The smallest deployment unit that exist in .NET is an assembly, but when you create an assembly (*.dll, *.exe), this makes them like small islands to comunicate them you need to use things like .NET Remoting to be able to let them talk, but the use of such power solution will make sense only if you are talking about processes(running in the back) or executable applications because either a private or public dll can be used in many applications at the same time with no problems.
Hope this help
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
