Transparent bitmaps

[Elisa]

Hi,

If you look at the .NET Compact Framework FAQ, and the PictureButton
example on the GotDotNet website, Microsoft recommends using Image
Attributes to specify a transparent color. They suggest to asume that
the upper-left pixel defines which color should be interpreted as
transparent.

But what makes me wonder is, surely Microsoft themself know of a better
trick, because if you add normal GIF files to an ImageList, and use that
ImageList in a ListView, it correctly shows the GIF files without us
having to specify which color should be interpreted as transparent, and
without relying on the "upper-left pixel is transparent" trick. Thus
they must know how to read the transparent color from the GIF files
directly.

So why won't they share their method with the rest of us?

I constantly wonder how much Microsoft must be out of touch with its
developer base (=us) to have made such poor decissions regarding what
functionallity should and shouldn't be dropped from the .NET Framework.
About 99% of us .NET Compact Framework developers' first task is to
write an ImageButton control, so why Microsoft insists it is "overhead"
is just beyond comprehension.


Regards,

Elisa

 

[Ed Kaim [MSFT]]

I am disappointed by your post because it implies that Microsoft has done
something that is negligent or malicious without asking for the whole story.
Microsoft is probably the most in-touch company with respect to the
developers that build software on its platforms. I was the product manager
for the .NET Compact Framework and can assure you that we made some very,
very tough decisions on what had to be cut in order to maintain the minimal
deployment package with the most functionality. In fact, we had cut the
DataGrid before Beta 1, but there was so much developer feedback that we put
it back in before release. This was the result of hundreds of customer
meetings across the entire product team, as well as the many other feedback
channels we use during the development of all of our products.
Unfortunately, some features just don't make the cut, whether for lack of
demand, size, feasibility, or schedule. One of the nice things about the
..NET Compact Framework is that it's easy to drop in new components, such as
the ImageButton provided on GotDotNet, for functionality that wasn't
included.

As for the GIF issue, if you go to
http://www.w3.org/Graphics/GIF/spec-gif89a.txt, you'll find the spec for
GIF89a. The GIF file format provides a list of all the colors each image
(GIFs can have multiple images in one file, such as for use in animation)
contains. Then, the actual pixels themselves are just index pointers into
the list, compressed using LZW. If you do a search within that page for
"Transparent Color Index", you'll find that each file also indicates which
color based on index, if any, is to be transparent in the the image when
drawn. The Microsoft implementation uses this standard, under license from
CompuServe, to draw GIF files appropriately. There is no secret here that
Microsoft is hiding from the developer community. Anyone can implement this,
given they do it under proper license from CompuServe.

However, the issue you're raising is why Microsoft recommends the usage of
ImageAttributes in order to draw transparency, and why the top left pixel is
called out as a prime source. First of all, ImageAttributes is the only
feasible way to draw transparency in managed code on the .NET Compact
Framework. Otherwise you'd have to go pixel by pixel and only draw the
nontransparent ones, which would be slow and painful. The reason the top
left pixel is offered is because it's often transparent in images with
transparency. Sure, it's not *always* transparent, but it's usually
transparent, due to its location in the image and the fact that most
pictures on buttons don't go all the way to the top left border. However,
you can decide that your standard chroma key color is bright pink (as many
do) and hardcode your ImageAttributes object to use that color for all
images, provided you do the work in the art to make sure the same exact
color is used on the transparent spots in your files, whatever format they
may be.

I hope this is helpful. If you have any further concerns or questions,
please email me by taking the "online." out of (e-mail address removed).

 

[Elisa]

Ed,

Thanks for your answer, I really appreciate someone standing up and
defending their product. Sadly, your answer itself just enhances my
feelings that you have at several points misjudged the requirements of
the .NET Compact Framework development community:

Software development projects these days have ever-tighter deadlines to
achieve, product development schedules are measured in days and weeks
rather than months and years. (And I sometimes feel that project
managers seem to think that because Mobile devices are smaller, writing
software for them should take even less time).

And under such thight deadlines, you would want us to find a copy of the
GIF89a spec, and develop a library that can interpret this type of file,
and draw the relevant pixels on a custom control, and add the correct
type of border around it, and show the button differently depending on
the state of the button (normal, pressed, focused, enabled, disabled, ...)?

All this just to be able to show a button with an image on it, a feature
available in any OS and any RAD tool that's on the market today (and for
the last 10 years or so)?!

You don't call that being out-of-touch with the real world?!?

Unfortunately, some features just don't make the cut, whether for lack
of demand, size, feasibility, or schedule.

Q: Is there sufficient demand for an ImageButton?
A: Well, for one thing, it is listed on the F.A.Q. pages on the MS
website, and F.A.Q. still stands for FREQUENTLY ASKED QUESTIONS. Also,
the whole of Windows CE itself uses buttons with images on them all over
the place, i.e. commandbar buttons, the input keyboard button, etc.
Image buttons make an ideal widget in screensize-constraint devices,
it's as simple as that.

Q: How much does it increase the size of the codebase?
A: Can't be a lot, because code to draw images is there already (e.g.
ListView, TreeView, ...), code to draw buttons is there already, even
code to draw images on buttons is there already (ToolbarButton). In any
case, if everyone starts writing their own ImageButton component, surely
more memory will be wasted than if an ImageButton component was part of
the .NET Compact Framework itself.

Q: How difficult is it to write this feature?
A: No doubt, a fully working, state conveying ImageButton is not an easy
thing to write, apparently it involves parsing GIF89a files ;-) But
honestly, it is SOOOOO much easier for Microsoft to write it (hey, the
code is in the full .NET framework!), then to force every Pocket PC
developer to have a go at it themselves!

One of the nice things about the .NET Compact Framework is that it's
easy to drop in new components, such as the ImageButton provided on
GotDotNet

I beg to differ! Firstly, the PicutreButton on the GotDotNet site is of
no use as-is (doesn't convey state, doesn't support transparency, ...).
More importantly, you can't just "drop" in a new component, you have to
add the control to your form programmatically, because writing Pocket PC
components with a design-time interface is extremely elaborate (and
isn't even possible with VB.NET)!

ImageAttributes is the only feasible way to draw transparency in
managed code on the .NET Compact Framework. Otherwise you'd have
to go pixel by pixel and only draw the nontransparent ones, which
would be slow and painful

Still, the ListView can do it, and it usually shows multiple images
instead of just one. So the underlying code must be available in Windows
CE somewhere (I actually know it is, as I used it in a previous eMbedded
Visual C++ project).

I'm sorry to disappoint you, but had I known as much about the (lack of)
functionallity (and robustness) of in the .NET Compact Framework as I do
now, I would recommended "pure" eMbedded Visual C++ over .NET anytime.
I'm sure with time that will change, but as for now, it is several steps
back instead of a leap forward.

Finally, if you take a poll on the 10-ten features missing in the .NET
Compact Framework, an ImageButton will be in the top three. Working
non-full screen modal dialogs and Thread Synchronization with Time-outs
will be in there as well ;-)


Regards,

Elisa

-----

 

[Chris Tacke, eMVP]

Elisa,

I think you are strongly biased toward your own development needs and
experiences. I for one have not had the need for a ImageButton, so it
wouldn't even come close to the top ten of my wishes. I would have liked to
see better thread support, window handles, better Control.Invoke support and
the ability to get WndProcs.

You must realize that the CF team, though they work at Microsoft, do have a
finite amount of time and finite resources, and that those have to be
allocated to delivering a specific product to a certain specification.
That's no different than any other development project.

You also must understand that this is version 1.0 of the product. Based on
my experience with many other companies and many other products, version 1.0
rarely satifies everyone.

I'm a bit surprised that you feel the lack of an ImageButton is such a
show-stopper that using eVC woul dhave made the entire project faster to
develop. I've done enough C++ UI development to know that is is a arduous
task that I will likely never do again because I can do it orders of
magnitude faster in managed code.

Sure, the GDN sample isn't full-featured - after all it's a sample. It
does, however, provide a pretty solid base on which to implement a control.
I don't think Microsoft is saying that every developer needs to create their
own controls. I think they're following the model they have for some time
of providing hooks and letting third-party sources create controls. This
allows better controls of a wider variety to be produced than if we all had
to wait on Microsoft to create what we want. As a case in point, have you
ever seen a good Grid control from Microsoft on the desktop or under CE? I
haven't, but there are great ones out there.

I'm not on the CF team, but I imagine they've had plenty of pressure to go
in many ways. I don't think it's productive to say they're out of touch and
aren't producing something worthwhile. How long would it have taken any of
use to do it? I see the CF as a great starting point, and a great v 1.0
product, but it's only that - a starting point.

 

[Elisa]

Hi Chris,

I think you are strongly biased toward your own development needs and
experiences.

No, actually I'm not, just look at the numereous messages and web pages
dedicated to this subject. And it's part of the FREQUENTLY ASKED
Questions. Surely it wouldn't appear on there if I was the only one
interested...

I would have liked to see better thread support, window handles,
better Control.Invoke support and the ability to get WndProcs.

But that is just the point: all these things are there already in the
underlying OS. Microsoft recommends going the .NET way for new projects,
which I blindly followed, only to get bitten in the back for believing.

I've developed Windows CE apps before (in C++), and I was completely
flabbergasted to find out the .NET Compact Framework is lacking so many
trivial features. If you start up a Pocket PC and look at the beautiful
GUI, you assume that all these cools widgets will be available to you if
you target that operating system. An ImageButton kind of widget was
lacking in the Palm-size PC, but finally arrived with the Pocket PC.
Only now to disappear again in the .NET Compact Framework!!!

From reading about the .NET Compact Framework, you would never come to
the conclusion that it actually lacks so many features that you know are
part of the underlying Windows CE OS. I can't iterate that enough:
currently, the .NET Compact Framework is a step back, it acts as a
barrier and prevents access to a lot of useful features in the
underlying Windows CE operating system.

As an application developer, I find it extremely difficult to explain to
my project manager that I need several days to write an image button. To
write a label that can do middle alignment. To write a non-fullscreen
modal dialog. To write ugly code to work around the lack of a
Mutex.WaitOne(10000) time-out call. To write a statusbar that can show
more than just text. Etc. Etc. Etc. The list just goes on and on and on.
All trivial stuff that has been around for years, even on Windows CE!

The number of messages in this newsgroup that go something like "you
can't do it in .NET CF, but you can P/Invoke it" are just staggering,
that in the end, you must come to ask: "Why bother?"

All these things come readily available in C++/MFC. Not only does
Microsoft make be believe that .NET is the way to go, and that I need to
give them a cool 1,000$ or so every year for Visual Studio .NET (another
point I don't get, why are we paying Microsoft money for tools to
write applications they require so badly to sell their operating
systems?! At least the eMbedded Visual tools were free!), believing in
..NET has made me loose complete control over my project, because I'm
spending ALL my time filling in the gaps in the .NET Compact Framework,
I've yet to write my first line of actual business logic.

And that is simply not acceptable in today's needle-sharp competitive
world. Anyone insisting that it is acceptable, really is out-of-touch
with the software development business.


Regards,

Elisa

 

[Paul G. Tobey [eMVP]]

So what's the solution? Wait until the .NET CF does *everything* that MFC
does before releasing it? I'm sure that everyone is disappointed at some
point in the feature set, but none of the things that you mentioned is a
killer, as far as I can tell. Can you write a program that works fine
without transparent bitmaps? Sure. 99% or more of programs *don't* use
transparent bitmaps. What about status bars with things other than text in
them? Sure. Again, 99%+ don't use anything but text. They're just
examples, but I'm sure you see where I'm coming from. I've never liked MFC,
so I don't know if maybe it was hatched fully-functional from the beginning,
but I rather think that it probably started in the same state relative to
the Windows API as we see with version 1 of .NET CF: it covers about 80% of
the possible area.

Now, I never felt that Microsoft was driving me toward .NET CF as the
preferred development environment for Windows CE, so maybe that's the real
problem. As far as I could tell, it was a new option (an extra thing that I
had to support, of course, as a hardware vendor), not a wholesale
replacement for other tools.

You don't have to pay $1000 every couple of years for VS.NET. You have to
pay it once, then maybe $50 every year or two for upgrades. I've already
made known my feelings about losing the ability to develop using at least
one free set of tools and will continue to do so in hopes of saving, in some
form, at least a free C++, but don't overstate the cost of using Visual
Studio.

Paul T.

 

[Elisa]

So what's the solution? Wait until the .NET CF does *everything* that MFC
does before releasing it?

Yes, that is the solution.

At the very least, don't spend millions to tell developers that .NET is
the next best thing since sliced bread, but make it clear that it is an
alternative to what is already there, and be clear in what the
adventages and disadvantages are.

Can you write a program that works fine without transparent bitmaps?
Sure. 99% or more of programs *don't* use transparent bitmaps.
What about status bars with things other than text in them?
Sure. Again, 99%+ don't use anything but text.

Yes, I CAN write a program that doesn't use any modern day GUI widgets,
yet I don't think I'd be able to find anyone to buy it. The whole
success story of Windows is in the fact that it looks stunning. Why then
Microsoft decides to come out with a product (.NET CF) that doesn't
allow you to use these stunning widgets, is beyond comprehension.

They're just examples, but I'm sure you see where I'm coming from.

Yes, from the DOS command prompt?

Now, I never felt that Microsoft was driving me toward .NET CF

Ah, then you must have missed them throwing Visual Studio .NET DVD's at
your face. You must have missed the multitude of .NET websites and
articles provided by Microsoft. You must have missed the huge .NET
marketing campaign Microsoft launched all over the world. You must have
missed the imposing .NET shows Microsoft organised in every town known
to mankind...

You don't have to pay $1000 every couple of years for VS.NET

Well, go to the Microsoft website, and they will at various points tell
you that the best way to get Visual Studio .NET, is to buy an MSDN
professional (or better) subscription. And that comes with a yearly
price tag of 1,103.08 EUR (excl. VAT) overhere, or about a $1,000...


Regards,

Elisa

 

[Dick Grier]

Hi,
Well, go to the Microsoft website, and they will at various points tell
you that the best way to get Visual Studio .NET, is to buy an MSDN
professional (or better) subscription. And that comes with a yearly
price tag of 1,103.08 EUR (excl. VAT) overhere, or about a $1,000...
<<

That is the best way for many (not all) professional developers. You get so
much more that just VS. You also get versions of all current OS's,
Microsoft Office, server tools, SDKs, and the MSDN itself (for the universal
subscription). Sure, there is a recurring cost, and revenue stream for
Microsoft, to be sure. However, if you need even a subset of these things,
then the subscription is the least expensive method.

That said, you don't have to get the subscription if you don't want to do
so. Just get Visual Studio Pro (or higher, US$484 at VBxtras), then plan to
spend about $50 every year or two to upgrade to the latest edition. The
MSDN subscriptions are the way to go if you want the extra features.

I never sneer at free or even low cost. Its simply is hard to pay the
electricity bill if you give things away. And, you cannot add features to
your developer products, if you cannot pay your programmers to develop those
features.

Now, don't mistake my intent. It isn't to make light of your needs. I have
"things" that the Compact Framework didn't provide, too. So, I had to do
some lower-level development than I would have had to do if MS had done
these "things." As it stands, those weren't in the Microsoft plans, so they
simply didn't happen.

IMO, Dick

--
Richard Grier (Microsoft Visual Basic MVP)

See www.hardandsoftware.net for contact information.

Author of Visual Basic Programmer's Guide to Serial Communications, 3rd
Edition ISBN 1-890422-27-4 (391 pages) published February 2002.

 

[Paul G. Tobey [eMVP]]

Unrealistic. When would it be done? Would MFC ever have existed if that
was the criteria?

Remember, Microsoft is *not* spending millions advertising the .NET Compact
Framework. They're spending millions advertising .NET. I have yet to see a
commercial saying that .NET is great because you can use it to program your
Pocket PC.

On the widget side, the existence of widget A should not be interpreted as
saying that you should use widget A in every program that you write (just
like the existence of templates in the C++ language doesn't mean that every
program should be full of template classes). A program with a good user
interface seldom uses all of the latest widgets. You may need one or two of
them to make the interface as transparent (no pun there), as possible, but
incorporating docking windows and image buttons just because you can is a
foolish shift away from 'function' toward 'form'. A flashy user interface
is a dead give-away to me that the author spent too much time adding every
control in the universe and not enough time (time being a constant, after
all), making the program work well.

As far as am-I-coming-from-the-DOS-prompt, no. In fact, back in the days
when the DOS prompt was the common interface on PCs, I used a Mac, where the
people in charge of the user interface *did* have some real training in
doing things to improve the user experience. They've since lost a lot of
the lead, but many of the lessons learned during those days could be learned
now by developers to the benefit of everyone. The simple things should be
simple for your user; the hard things should be as simple as possible for
her. No where in that does a transparent bitmap, a status bar with various
icons in it, image buttons, or docking toolbars become a requirement. As
soon as you equate a good user interface with a long list of controls used,
you've missed the point.

As far as directing people to MSDN, sure, why wouldn't MS do that? Given
the choice between selling your software one time for $50 and selling a
subscription every year for $50, which are you going to pick? The fact is,
though, that you don't have to spend that money every year to get .NET CF
development and that, if you do spend the money, you get a heck of a lot
more than just VS.NET.

Again, I'm sorry that you feel betrayed, but I think that, if you can get by
that, you'll see that .NET CF is a good way to build high-level
applications, with lots of capabilities, for your Windows CE-based devices.
It's not perfect and probably never will be, but the lack of some
capabilities doesn't make it useless...

Paul T.

 

[Boris Nienke]

In fact, we had cut the
DataGrid before Beta 1, but there was so much developer feedback that we put
it back in before release. This was the result of hundreds of customer
meetings across the entire product team, as well as the many other feedback
channels we use during the development of all of our products.
Unfortunately, some features just don't make the cut, whether for lack of
demand, size, feasibility, or schedule. One of the nice things about the
.NET Compact Framework is that it's easy to drop in new components, such as
the ImageButton provided on GotDotNet, for functionality that wasn't
included.

Hi,
i wonder why:
- you have cut the DateTimePicker from the CF? You know, the CF is running
on PocketPCs. What is a PocketPC for most users in first case? A device
to track appointments, task and addresses.

If you write a pro-application for the business-market, i think you
allways will come to the point where you need the user to enter a date or a
time.

- you don't offer an interface to the POOM?
You know: a business-user want's to use it's contacts and appointments in
a user-defined application too! So if you write some applications to plan
projects etc. you like to show the milestones as appointments - not
possible! you like to browse the contacts that are linked to the projects
in your application - not possible!

these are just two examples where i think, that MS hat not thought (enough)
about what the CF is for (and who will use it). But i hope that there will
be a version 2 that fixes that.

the problem:
- until such version2 (that MAY come) everybody has to write his own
controls... and so every application will "feel" different.
- there is no POOM in .NET CF - so it will be easier (and faster) for one
to write some input-masks and design some tables to make a OWN contact
database and a OWN appointment base etc... sure, will work for THIS
application... but the user won't understand why to enter the contact two
times...

Boris

 

[Ed Kaim [MSFT]]

DateTimePicker:
http://msdn.microsoft.com/library/d.../en-us/dnnetcomp/html/netcfdatetimepicker.asp,
designer support at
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetcomp/html/DTPick_WD.asp.

POOM
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetcomp/html/inthehandpoom.asp.

 

[Enrico Bizzarri]

eVB was the "bugs paradise" but they say to me "don't worry .net will be the
promise land"

Now CF is the "sorry only for the full Framework" or "Why don't you write
all yourself?" or again "not in 2003? Will be in 2004 or 2005 or......"

..NET is the future, is a good thing (you can do amazing things with it). But
is young too young, in italy we say "...making the step longer than leg
is..."

IMHO MS have to stop a moment to say what the world will do with .net, not
announce a new version every 8 weeks!

I'm not able to program in 2003 yet, and they talk about 2004! Ok and my
nowaday problems?

Byez and sorry for the OT

Enrico

 

[Paul G. Tobey [eMVP]]

Yes, the people using eVB did get the run-around. I don't know if there's
anything that MS could have done that would have been good enough, in that
case, given what eVB is/was, but I hear you, and I'm sure that the product
managers at MS for the .NET CF do to...

Paul T.

 

[Paul G. Tobey [eMVP]]

or maybe "do, too..."

Paul T.

Yes, the people using eVB did get the run-around. I don't know if there's
anything that MS could have done that would have been good enough, in that
case, given what eVB is/was, but I hear you, and I'm sure that the product
managers at MS for the .NET CF do to...

Paul T.

 

[Boris Nienke]

First of all - i'm talking about a out-of-the-box-solution - not about
buying something for n-thousend bucks and then crawling the internet to
hopefully find something which is just "close" to the original controls...

DateTimePicker:
http://msdn.microsoft.com/library/d.../en-us/dnnetcomp/html/netcfdatetimepicker.asp,
designer support at
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetcomp/html/DTPick_WD.asp.

it's a DATE-Picker... NOT a Time-Picker!
And: it's buggy... in fact, i use it because it was the best solution i
have found.

But:
- it's hard-coded in english! i have translated it to german.. but still
not device-dependend (this control will show "january" 12 times if you
click on the month to select another because it assumes the whole world is
using MM.DD.YYYY as date-format
- it starts with the week at Sunday... i had to crawl it to change it to
start with monday... no property yet - i've just hardcoded it
- no week-of-year column (currently don't know how to change the code to
display that)
- NO Time-Picker to let the user easily enter a time without struggling
with the ":", entering just 2 decimals before/after the ":" etc...
- If you have the calendar open you MUST select a day to close the popup..
clicking anywhere else on the screen won't close it

....You know... if someone has to code an own Date/Time-Picker... why is
there already an edit-box and a list-box etc...? Wouldn't it be enough to
have just some string-functions and a function to let a cursor blink? Then
you could do everything with some paint-functions ;-) ... just kidding...

POOM
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetcomp/html/inthehandpoom.asp.

i know ;-)
But what i meant was:
- if designing a "Compact"-Framework that is planed to be used for
Smartdevices like pocketPC - why not offering out-of-the-box functions or
ready-made-DLLs to let the developer use the special functions of the
device?

I think there are routines for using the InfraRed-Port? Right? These are
not available on the Framework for Desktop - right? So there are some
specials... but i think someone has not thought far enough (not sure)

For me - i was very surprised by how low the level of the CompactFramework
is (in many points)

Boris

 

[Boris Nienke]

Full Quote!

Thats exactly how i feel for years!

I've started with an old "everex freestyle" (WinCE 2.11) because i thought:
"i'm a windows-coder so it would be easy to write software for pocketPC"...
i was wrong! Nearly no support at all

Then, years later, i bought a device with PPC2000 ... still no way to write
own software like i did/do for Desktop-Windows.

Don't remember if now eVB/eVC++ comes first or the Update to PPC2002...
I've looked at eVB ... not really a language <sig>
I've looked at eVC++ ... too hard for me (i'm not a C++ coder and don't
know about the logic of the MS IDE... a friend shows me how to start (on a
Desktop MS-C++) but it was not possible to make it so with eVC++ because of
some bugs (if this options is set then this won't work (it should but it
doesn't work) etc.)

Unfortunatly we Coders are left alone by others... Borland won't make
anything for PocketPC ... sad...

THEN there was it: .NET - the promised land... Use one code on EVERY
device/machine because it's .NET....

Ha! But it's "compact" framework... so you cannot really use the
Desktop-code and vice versa (only if it's very simple)...
- no simple database anymore (SQL-Server is simply overkill for many apps)
- very simple standard-controls are not available or not completly working
- no interfaces to pocketPC-specific things like contacts etc. (OK, now i
could by it from InTheHand - but you know what i mean?)
- damn slow emulator (and it needs x86 code - no REAL emulator)

And if you ask for a solution:
- use P/Invoke (which makes re-using the code for desktop hard/impossible)
- use override for Paint-Event and do it yourself (wow...)
- use eVC++ to write an own wrapper... (then: why not coding it completely
in eVC++?)

But in fact: it's the very first time i was able to really write a small
application for PocketPC.. hey.. we have 2004 now ... Maybe in 2006 we
don't need this crippled stuff anymore because something like WinXP is
running on that devices too?

;-)

I still have hope that things getting better... but if i compare the free
tools eVB/eVC++ with the very expensive tools for .NET-CF ... then i have
to say it's not that good for .NET-CF :'(

Boris

 

[Paul G. Tobey [eMVP]]

You *can* buy devices that run Windows XP, although I'm not aware of any in
the same form factor as PPC devices. It *is* advantageous in many ways to
have several hundred MB of RAM, a hard disk, etc., but, then again, in a lot
of industrial situations, a "no moving parts" solution is a lot better.
Everything has its trade-offs. Imagine if Windows CE had a completely
different API than desktop Windows, for example...

As far as C++, you could learn. You learned VB somehow, right? You
understand that virtually every programming structure in the world is one of
sequence, repetition, and selection. It's no different in C or C++. Only
the precise syntax is different. I've never taken a class in C, myself. In
school, a class I needed to take required coding in C, so I had to pick it
up as I went along. A few weeks with K&R and lots of syntax errors for a
while, but I'm pretty adept now...

Paul T.

 

[Hutch]

Ed -

After using the compact framework for a few weeks, I do think the team
needs to be congratulated for developing a quality product. From what
I can see, it is a rock solid application. Any time a product team
places quality at the front of the list, their user community
ultimately is the primary beneficiary.

Putting quality first in software development is definitely "in touch"
with the user community. It represents excellent decisions in making
a better product, creating better software, and faster future
innovation. Trading a single feature is very rarely worth compromise
in this area.

And for those reading, I too definitely have had mixed feelings and
some frustrations working with .NET CF. But *my* request would have
been better marshalling support, specifically callback support. So
.... I guess the user community isn't 100% unanimous about a datetime
pickers ... or even HTML viewers.

Kevin Hutchison

 

[Boris Nienke]

You *can* buy devices that run Windows XP, although I'm not aware of any in
the same form factor as PPC devices. It *is* advantageous in many ways to
have several hundred MB of RAM, a hard disk, etc., but, then again, in a lot
of industrial situations, a "no moving parts" solution is a lot better.

i was talking about a PocketPC-Devices (no moving parts!) that will run
something like XP (or an other desktop system)
Memory is getting cheaper and cheaper. You can buy a CompactFlash Card with
4 Gigabytes :-O ... wow! Why not installing Windows on it ;-) ... because
it's slow... today! but the engeneers are working on the speed every day.

As far as C++, you could learn.

i don't have any problems with C++ ... just with the MS-IDE

You learned VB somehow, right? You

well... not really ;-)
I've learned Basic on an old C-64 ... then a GW-Basic on an old PC (8088
with 4,.. MHz). VB isn't that much different... still Basic

i could code COBOL or Pascal/Delphi ... and a bit C# now

understand that virtually every programming structure in the world is one of
sequence, repetition, and selection. It's no different in C or C++. Only
the precise syntax is different.

yes - right!
But with the IDE of VC++ or eVC++ everything is very complicated (at least
for me) and you have to care for EVERYTHING ... may be nice when you like
to have a very small EXE... right... but when writing a commercial
application with just text-interface (edit-fields etc.) i don't like to
care about tons of Windows-Events like "click", "move", "activate" etc...
Today i like the idea of heaving a framework around of it...

Take a Delphi-Coder and a C++ Coder in one room and tell them to code a
simple Appointment-Application. I bet that the Delphi-coder is ready long
before the C++ coder... but the EXE maybe a lot smaller with C++ and
_maybe_ a _bit_ faster... But TIME is money...

And as said: the VC++ coder wasn't able to use eVC++ because some bugs are
in there... if you don't know them, the wizards and something are not
working correctly... But it's free - so i won't tell anything too bad about
it

Everything is a lot more complicated in eVC++ ... so i like C# a lot. But
then... i cannot build a Today-Screen-Plugin (have to write a C++ wrapper
- but then i better go an write the whole thing in C++, or not? ) or other
Plugins for Task-Line etc.

....and many standard-controls are not available etc...

For example:
- i need to highlight some lines in a ListView when some value is
reached... but there's no ownerdraw to color some items/lines :-(

So i think i need to write my own list from scratch! You know that this
isn't an very easy job... you have to take care of the headers (which could
be resized), the scrolling etc...

to sad... it's always the simple things... the last 1% that is missing...
(There's a "Combo"-Box... not very Combo, isn't it? ... try to edit some
data )

Boris