Oliver Sturm said:
Embedding Excel in your application allows you to edit Excel files in a
window that looks like it's an integral part of your application, that's
all. Of course an Excel sheet can, in turn, be configured to retrieve its
data from an external source, which may happen to be the same data source
(i.e. database) that your application also uses. But even though Excel is
visualizing its output inside one of your application windows, it's still
Excel running there and it does its own job very much like it would if it
were running on its own.
**You're right about that.
But that's exactly the crux - for certain kinds of input, Windows Forms
is pretty bad. Theoretically you could create a control that would
emulate the table-oriented editing capabilities that Excel has, but
that's extremely complex and why bother if Excel is already there? OLE
(note the "E" - it stands for "embedding") was going to solve that
dilemma, and I do think it's a pity that the idea has been more or less
abandoned in .NET. It was probably never perfect, but it allowed for
amazing functionality if used correctly. Of course it's still possible
today if you use the existing APIs... only it's a lot of work and there
are fewer developers around than ever who know how to code that kind of
thing themselves. OLE automation may suffice to remote control an
application, but it doesn't give you the integrated look and feel and
handling that object embedding does.
I guess I haven't had any problems using Windows Forms for anything I've
done, except in VB6 the form couldn't be larger than the real estate, and
that was annoying, but sort of circumventable with Tab controls.
I've done a *lot* of reporting with OLE Automation, and am really hoping it
still works with Office 2007. I'm not sure how much of it is going to be
broken. My users in the corporate world *love* Excel, and being able to
dump their data and muck around with it makes them really, really happy.
I haven't ever used Excel for modifying data because I'm more
anal-retentive than that -- I *really* like to validate the heck out of
data before trying to store it. In VB6 I beat the Heirarchical Grid into
submission (phew, that was exhausting), and in VB2005 I'm using the
DataGridView, although I still prefer to have an edit screen for a specific
record because it gives me more control.
Yeah, I know it does
Sharepoint or not - Microsoft is envisioning
Office to be the platform for applications these days, not "just" the
tool that's being used by other applications. And granted, VSTO does
amazing things in many ways. But it doesn't give developers the freedom
to integrate in the way they want (focusing on their own applications as
the central platform instead of Office) and it also doesn't do much to
improve the often stupid and restricted data and event models that most
Office applications work with (but that's a completely different topic).
I agree with that. I think they're driving Office because customers found
ways to do things with it that Microsoft never thought of and now they can
use that to market to other people. Who ever thought you'd need more than
65,000(ish) rows in a spreadsheet, or more than 255 columns? Frankly, I
think there's a point where it's too much data to absorb, but you know how
customers are -- they know best.
I was annoyed that VSTO was a separate product than VS2005. I would have
liked to play around with it, but no way was I going to buy two of them.
Why couldn't it be a plug-in for VS2005?
During the presentations at the launch, someone said the new one is an
add-on to VS2005. It apparently works with Office2003, too. And it actually
is an add-on, but if you have VS2005Pro, you don't get any "document-level
customizations or other functionality that is part of the full version of
VSTO 2005; VSTO 2005 SE adds only the application-level features..." So you
have to have Team Suite or original VSTO to get the whole shebang.
The only big problem I had with the demos at the Launch is I couldn't
easily tell what was Sharepoint, what was InfoPath, and what was Office. I
suppose that's part of the selling point, but as a developer, I need to
know what I'm going to need to know, if you know what I mean. And they
didn't show the code connecting the stuff, or tell how you're supposed to
do that. At one point, I did see some .net code (for 2 seconds while they
were flipping through screens) with a Sharepoint namespace, but that's all
I know about it.
The WPF stuff is pretty cool; I'm learning that now, and it *really* lets
you imbed stuff all over the place. Haven't tried imbedding office in it
yet, though.
What in the world does *that* mean?? It doesn't even have enough characters
for me to figure it out by pattern recognition (I do cryptograms). Please
don't leave me in suspense!
Robin S.
