UtterAccess.com
X   Site Message
(Message will auto close in 2 seconds)

Welcome to UtterAccess! Please ( Login   or   Register )

Custom Search
 
   Reply to this topicStart new topic
> Wpf V Access Arguments    
 
   
ConorS
post Feb 24 2014, 11:14 AM
Post#1



Posts: 1,357
Joined: 1-April 04
From: Northern Ireland (Newry)


Hi
've been working with Access databases for about 10 years now. I'm looking to branch out a bit. About 5-6 years ago i leaped into Ms SQL Server backend databases with Access front ends.
I am now looking into Windows Presentation Foundations interfaces with SQL backends.
There is my question. If yous could help me summarise.
What as a front end does WPF have that access doesn't have? (i'm not very good at articulating it)
I'm trying to sell the idea to the business i work for.
And, "it looks much prettier" isn't going to cut it.
If anyone could help summarise to a higher level that would be great
Thanks
Conor
Go to the top of the page
 
jleach
post Feb 24 2014, 03:17 PM
Post#2


UtterAccess Editor
Posts: 9,812
Joined: 7-December 09
From: Staten Island, NY, USA


WPF is, as the name states, a Presentation Framework. This basically means that it was designed as an advanced tool to create excellent graphical interfaces.
ccess, on the other hand, is generally pretty cut and dry as far as graphical abilities go.
WPF has a nasty learning curve, in my experience. I won't claim to know it inside and out, but I've done decent amount with it here and there. You will still be working on SQL Server, on top of which you will have your logic programmed in C# or maybe VB.Net, and then from there you basically have your choice between WinForms or WPF. WinForms tends to resemble what we recognize coming from an Access background much more than WPF does... things like the basic controls and data bindings are quite a bit more straightforward and not too difficult to wrap the head around.
With WPF, the entire form/control structure is far different than WinForms/Access. The amount of control you have over it is amazing, but it comes at a price of complexity. You can make a button look like a tree, if you wanted, but to change the appearance of the border on a button you need to go through multiple layers of style and control templates to, more or less, create your own button template that has a thinner border or no border or a bit less of a corner radius. Something so seemingly simple is not very simple at all.
However, this isn't to say that it's all very difficult. Once you get past the binding structures, using WPF as a basic presentation layer for a SQL Server application isn't all that terrible - most things that most people need to do are easy enough where you don't have to redefine a control from the ground up to get it working. One of the larger projects I did in WPF was a 2d CAD/CAM program for drawing geometry on the screen with zooming, panning, hit testing, etc. It was an awesome project to work on, because WPF made it very easy for that type of work (well, relatively easy, we'll say), and the results were very smooth and slick, though I did have to pay a lot more attention than I expected to performance handling.
Check this out: http://blogs.msdn.com/b/kaelr/archive/2009...rtualpanel.aspx
Imagine putting 10,000 or 100,000 shapes into a canvas to be displayed via zooming/panning, etc. The way WPF handles this is absolutely amazing.
One of the other big points to WPF is that the binding (dependency properties, as they're called), is set up to allow designers (non-programmers) to handle a lot of the actual behavior as it interacts with other elements of the presentation. For instance, if this control changes, change these and these and these to look like that and that and this - all without writing nearly as much code as was required in a heavily event driven model in windows forms, thus making it easier for large teams of developers to assign design teams to do their own work without necessarily relying on the programming team to write a lot of behind the scenes UI logic. Nice for companies with those kinds of requirements, but for us little guys, that advantage is of little significance.
In comparison, lets take a look at an "old" WinForms example compared to Access. Take your standard Access combobox or listbox, which is pretty cut and dry. If you want to include images or maybe checkboxes, etc, you have to resort to third party ActiveX controls which general come with a host of disgusting versioning issues. With .NET in generally, stuff like this is a breeze. You get way more customization of just about every control. Datasheets (called GridViews in WinForms) can have buttons on them, the continuous form equivalent isn't "the same instance of the same control" like they are in Access, so you can individually manage each control on each record. Aside from the .NET code framework itself, these are some of the visual differences.
In Access, using compiled or runtime applications, we're not allowed to create new controls. Say you want a sidebar of buttons for each module: you need to have all of them defined in the form, then show only those you want. In .NET, you have the ability to create them on the fly without those kinds of restrictions. Just about every Windows API programming task that we'd have needed in VBA is built in as part of the framework in .NET: it's a really nice framework and easy to code with. There's tons of support for all sorts of common tasks: serialization, working with XML, web services... stuff that Access itself isn't great with out of the box but can be done in VBA is pretty much out of the box with .NET (for the most part, anyway).
Again, it's hard to articulate the difference. WPF in itself is kind of a different beast that sits on the .NET framework, but I suspect you're really wondering what the .NET framework in general has to offer over Access. Note that Access/VBA is built on COM, which is a technology that MS would likely rather not continue with but has no real choice for many years yet since so much is COM based.
Anyway, I could go on and on, but that's enough from me for now.
Cheers,
Go to the top of the page
 
ConorS
post Feb 25 2014, 05:37 AM
Post#3



Posts: 1,357
Joined: 1-April 04
From: Northern Ireland (Newry)


Thank you for the long reply. I appreciate the way you answered my question.
hey are all great points you make. I've been developing a WPF app and i plugged in Dev Express for WPF and i am getting amazing results with graphs and charts. The ability to drill down through charts i'm sure will go down well with the stakeholders.
Essentially it is a much prettier and easier to use front end.
Access to the .net framework is definitely a big plus.
Go to the top of the page
 


Custom Search
RSSSearch   Top   Lo-Fi    16th December 2017 - 08:02 AM