PowerBasic or Visual Basic?

[James McNab]

Hi guys,

having been away from programming for many years and having time on my hands, I thought I'd have another go at it. One thing is immeadiatly clear - we're not in Kansas anymore Toto.

I've been doing some research and a lot of reading and I've settled on using some dialect of Basic, which brings me to choose between PowerBasic and Visual Basic. It appears to me to be PowerBasic for performance and Visual Basic for everything else. I have conserns about PowerBasic, one of which being the appearant lack of interest in the world outside Power Basic. Unless I've missed something, the users of PowerBasic rely on you for translations of the newer parts of the Windows API. Even FreeBasic, (not a contender) provides headers for some of the more common third party DLLs. Also PowerBasic doesn't appear to address WMI which looks like a pretty important technology, or USB (all the stuff I've gleaned about Powerbasic and comms seems to only refer to serial?)

Are these points true? and are they relevant?

I don't pretend to understand this but I found the thread - "Need complete, simple example of a PB/Win COM DLL with calling VBSCRIPT code" - on the PowerBasic board disconserting - it appeared to take the combined efforts of the most authoratative posters to solve a problem which I suspect wouldn't have been an issue in Visual Basic. True?

Anyway, any comments from you Jose or any PowerBasic users as the pros and cons gladly accepted.

BTW If anyone wonders why I'm posting these questions here and not on the PowerBasic board - the staffers who post on that board seem to have a fairly high handed atitude and seem to have issues with anything construed as critisism. Plus I don't need the sales pitch.

James McNab

[José Roca]

 
Which flavor of Visual Basic, VB6 or VB.NET?

PowerBasic doesn't appear to address WMI which looks like a pretty important technology, or USB (all the stuff I've gleaned about Powerbasic and comms seems to only refer to serial?)

You can use WMI with PB easily. You can find examples here: http://www.jose.it-berater.org/smfforum/index.php?board=229.0

Regarding USB, I have recently translated the headers for the HID.DLL: http://www.jose.it-berater.org/smfforum/index.php?topic=3853.0

With PB you can use all what Windows provides, without the need of ActiveXs or .NET assemblies.

I don't pretend to understand this but I found the thread - "Need complete, simple example of a PB/Win COM DLL with calling VBSCRIPT code" - on the PowerBasic board disconserting - it appeared to take the combined efforts of the most authoratative posters to solve a problem which I suspect wouldn't have been an issue in Visual Basic. True?

This is a shortcoming of VB, that is unable to use a COM server unless all its particular requirements are fulfilled. With PB you can use them even if they are not registered. I have been doing it years before M$ came with its convoluted way of doing it ( http://msdn.microsoft.com/en-us/library/ms973913.aspx ). All you need to activate a COM server with PB is the ClsID (Class identifier) and, if it is not registered, the path of the .DLL or .OCX.

PB is a wonderful compiler for those like me that like low-level programming, not by masochism but because your applications run much faster and use less resources.

[Peter Weis]

Hello José Roca,
Dus me speak from the heart, it is possible in PowerBASIC COM DLL call I wonder if they are not registered! And with an ease which even C programmers can only dream

I Work in a large company where it is not possible to register OCX modules that simple. By using Power Basic jukt me not even a simple I bind the OCX whom she is on the computer

Example:

LET ufreedb = NEWCOM CLSID $CLSID_pbfreedb_FREEDB LIB "pbfreedb.dll"


And now you can use the object

Regards Peter

[Edwin Knoppert]

>LET ufreedb = NEWCOM CLSID $CLSID_pbfreedb_FREEDB LIB "pbfreedb.dll"
This won't work if the activex needs another activex and most likely loads it via the registry.

(The technique Jose describes works differently and i have no sayings about that one right now)

[Peter Weis]

Hello Edwin,
Maybe I've misunderstood, but it really works and I can also access the this object to another is Registered. The freedb object is not registered! And just in a DLL

Here's an excerpt

Code Select Expand



CLASS freeDB GUID$("{E77563CD-28AE-4822-9169-82F9BD934E23}") AS COM


    INSTANCE enumCDDBMode       AS uCDDBMode




    INSTANCE m_MatchCode        AS uCDDBMatchCode
    INSTANCE m_UseFirstMatch    AS Boolean


    INSTANCE m_CdTextInfo           AS STRING
    INSTANCE m_Genre                AS STRING
    INSTANCE m_AlbumSeconds         AS LONG
    INSTANCE m_Tracks               AS INTEGER
    INSTANCE m_Notes                AS STRING
    INSTANCE m_Year                 AS STRING

    INSTANCE m_MediaTOC             AS STRING
    INSTANCE strUserEmail           AS STRING
    INSTANCE m_DAODir               AS ASCIZ * %MAX_PATH
    INSTANCE m_strCDDBFilePath      AS ASCIZ * %MAX_PATH 'STRING
    INSTANCE strCDDBServer          AS STRING
    INSTANCE m_AllowSubmit          AS Boolean
    INSTANCE strAppName             AS STRING
    INSTANCE m_MediaId              AS STRING
    INSTANCE m_Category             AS STRING
    INSTANCE m_ArtistName           AS STRING
    INSTANCE m_AlbumName            AS STRING
    INSTANCE m_QueryString          AS STRING
    INSTANCE m_Revision             AS INTEGER
    INSTANCE strAppVer              AS STRING
    INSTANCE m_cdType               AS INTEGER
    INSTANCE m_ReadType             AS INTEGER
    INSTANCE m_hDlg                 AS LONG
    INSTANCE frmFuzzy               AS fFuzzy
    INSTANCE frmSites               AS fSites


    INSTANCE m_dbWorkspaces         AS Workspaces
    INSTANCE m_dbWorkspace          AS Workspace
    INSTANCE m_dbDatabase           AS Database
    INSTANCE m_dbTableDef           AS Int__TableDef
    INSTANCE m_dbEngine             AS Int__DBEngine
    INSTANCE m_dbEngineEnable       AS INTEGER
    INSTANCE m_DAOAutoSave          AS INTEGER
    INSTANCE m_DAO_Update           AS INTEGER
    INSTANCE m_DAO_Enable           AS Boolean
    INSTANCE m_DeleteFreeDB         AS Boolean
    INSTANCE m_CDTEXT_Enable        AS Boolean
    INSTANCE m_internet_Enable      AS INTEGER
    INSTANCE m_QueryLocal_Enable    AS Boolean
    INSTANCE m_TOC                  AS STRING


    'INSTANCE m_TEXT             AS STRING



    GLOBAL colTrackNames    AS ICollection
    GLOBAL colTrackCDNames  AS ICollection
    GLOBAL colTrackTimes AS ICollection
    GLOBAL colTrackNotes AS ICollection
    GLOBAL colServers    AS ICollection


    CLASS METHOD CREATE()
        colTrackNames   = CLASS "CCollection"
        colTrackCDNames = CLASS "CCollection"
        colTrackTimes   = CLASS "CCollection"
        colTrackNotes   = CLASS "CCollection"
        colServers      = CLASS "CCollection"
        frmFuzzy        = CLASS "frmFuzzyMatch"
        frmSites        = CLASS "frmServerSites"
        frmSubmit       = CLASS "frmSubmitInfo"

        #IF %DEF($PROGID_DAO_DBEngine36)
            m_DBEngine =    ANYCOM $PROGID_DAO_DBEngine36
        #ELSE
            m_DBEngine =    ANYCOM $PROGID_DAO_DBEngine120
        #ENDIF

        IF ISOBJECT(m_DBEngine) THEN
            m_dbWorkspaces      = m_DbEngine.Workspaces()
            m_dbWorkspace       = m_dbWorkspaces.Item(0)
            m_DBEngineEnable    = %True
        ELSE

        END IF




    END METHOD


    CLASS METHOD DESTROY()
        colTrackNames   = NOTHING
        colTrackCDNames = NOTHING
        colTrackTimes   = NOTHING
        colTrackNotes   = NOTHING
        colServers      = NOTHING
        frmFuzzy        = NOTHING
        frmSites        = NOTHING
        frmSubmit       = NOTHING

        m_dbWorkspace   = NOTHING
        m_dbWorkspaces  = NOTHING
        m_DBEngine      = NOTHING

    END METHOD



    '**************************************************************
    '** GetPossibleRecord (STR Path of the local Files of FreeDB,**
    '**  STR Subdirectory, STR MediaID)                          **
    '**        returns a string with the name of the file, where **
    '**        the selected album could be in (without path)     **
    '**************************************************************

    CLASS METHOD GetPossibleRecord(BYVAL sppath AS STRING, spKat AS STRING, spDiscID AS STRING) AS STRING
        LOCAL dbDatabase    AS Database
        LOCAL dbRecordset   AS Recordset


        IF RIGHT$(sppath, 1) <> "\" THEN sppath = sppath & "\"
        dbDatabase = m_dbWorkspace.OpenDatabase(UCODE$(sppath & "FREEDB.MDB"))
        IF ISTRUE ISOBJECT(dbDatabase) THEN
            dbRecordset = dbDatabase.OpenRecordset(UCODE$(spKat), %dbOpenDynaset)
            IF ISTRUE ISOBJECT(dbRecordset) THEN
                dbRecordset.findfirst(UCODE$("DISKID = " & "'" + spDiscID + "'"))
                IF dbRecordset.NoMatch THEN
                    METHOD = ""
                ELSE

                    METHOD = VARIANT_TO_STR(dbRecordset.collect(0))
                END IF
                dbRecordset.CLOSE
                dbRecordset = NOTHING
            END IF
            dbDatabase.CLOSE
            dbDatabase = NOTHING
        END IF
        METHOD = ""
    END METHOD
                                       



As you can see is called in my DAO object freedb object, this in turn is regestriert.

Regards Peter

[Frederick J. Harris]

All through the nineties Visual Basic was incredibly popular.  I believe there is some statistic I saw somewhere to the effect that there were more VB programmers than all the rest of the languages combined.  I may be wrong about that, but VB was a truely powerful product.  I used it hard up to around 2004 or so.  After that I started switching to PowerBASIC because of .NET.  That was pretty much the 'schism'.  I tried hard to like .NET but just couldn't pull it off.  I spent about 6 months working though about a half dozen VB.NET & C# books, and finally just admitted to myself I hated it and would seriously consider giving up programming if that was all there was.

Since I was pretty good at C coding I was considering using C as my main language; maybe learn a bit more C++ too; but I soon discovered I could have the best of both worlds with PowerBASIC.  I could have small fast executables with no dependencies, plus the high productivity of an excellent standard BASIC dialect.

In the early 2000 time frame I don't think too many PowerBASIC users were making apps that would compare very well with Visual Basic apps in terms of fancy user interfaces, or containing high-powered COM functionality.  But that has changed totally within the past several years thanks in large part to Jose's work plus of course the compiler itself now supports COM and OOP.

Another issue with me is that I felt no compulsion to follow the crowd with .NET due to its being what everybody else was doing in terms of furthering their carreers or anything like that (I'm old enough not to be worrying about that).  I chose PowerBASIC because I like it and felt it to be my best choice for the coding I do.  I definitely like procedural style programming, and only use OOP to a fairly small extent.  I'd classify myself as a low level coder.  That was one of the things I didn't like about .NET - too high level.  Basically, with .NET, my impression is that most folks spend their time scouring the net for code snippets to do this that, or the other thing, or searching help for how you string nested object references together to accomplish what you want.  To me, that isn't programming, and I get little satisfaction from it.  

As things stand now with me I spend about half my time using PowerBASIC, and the other half with mobile devices and C/C++.  If PowerBASIC produced a compiler for Windows CE I'd probably abandon C/C++ and only use the reference material on the Apis which are in C mostly.

[José Roca]

Maybe I've misunderstood [...]

He means that if the loaded OCX creates an instance of another OCX not using a registration free technique, and this other OCX is not registered, it will fail. Of course. This is like if you use an standard DLL that has a dependency of another DLL and this other DLL can't be loaded because it is not in any of the suitable folders.

It would not happen if the OCX will check first if the other OCX is in the same folder, in which case it will load it using a registration-free technique, and using the CoCreateInstance way if it can't find it.

My point is that neither all that registry crap, nor type libraries, are needed. It is only a requirement of Automation languages.

[Frederick J. Harris]

I have conserns about PowerBasic, one of which being the appearant lack of interest in the world outside Power Basic.

That is interesting James, and I've spent a lot of time wondering about it too.  All I can say about it is that kids in college are going to be pushed into the newer Microsoft technologies, probably C/C++/C# if in Computer Science/IT majors, and .NET if in various technical specialties.   PowerBASIC seems to be something a small percentage 'discover' in one way or another.  Alternately, many of us have been around programming languages practically since the beginning of PCs, so its not too big a jump to have discovered PowerBASIC somewhere along the way.  The one thing I'm quite certain about is that I wouldn't let PowerBASIC's lack of exposure in the college classroom or anywhere else worry me in terms of its value.  Its a gem.  In these forums you'll find a lot of professional programmers fluent in many languages or expert in PowerBASIC who use it to earn a living. 

In my particular circumstance where I work, we had a mission critical app we spent millions of dollars on, designed and written by a team of professional programmers, and the thing barely worked and ran so poorly we were always being told we needed to be buying bigger and more powerful servers to keep it running.  It was costing us on average $250,000/year in contractor fees to keep it patched and running, and another $29,000/year in license fees for the particular app development tool used (I don't want to mention names).  I replaced it with a PowerBASIC app whose total size is around 900K (in other words, it would easily fit on a floppy).  Its performance in everything it does is all but instantaneous.  The program is a single exe and a dll containing a custom control grid.  So we now have a perfectly performing application thanks to PowerBASIC and are approx $300,000 per year richer.  I'd call that value.  So my take on PowerBASIC's lack of exposure in the mainstream programming world is that its their loss for not being aware of it.

[Eros Olmi]

Mr Zale will claim for some of that $300,000   

[Edwin Knoppert]

It's really hard to tell if they where actually professionals + the fact of having a lot of programmers may result in poor guidance.
Incorrect/poor guidance is one of the most problematic issues imo.
Sounds to me that the person who wrote it in PB was a single programmer?
The guidance needed may be totally different then with the larger group.

The PB variant may have been the better choice from the start, you may call it poor descisionmaking to use a tool which costs so much money..

Imo you can not compare programming languages this way.
If you where very good with .NET i am sure you where fine with it too, .NET has many more (self)described features (but also some limits).
In PB nothing is described besides some silly helpfile and MSDN.
Also the debugging is a poor thing, for example when i use PwrDev code for debug i get code i really don't want to debug but stepping takes serious time.
Compare that to a winforms app where these details are hidden, the debugger skips these parts so you only need to deal with the custom code.

There are many aspects which are hard to compare, your PB app may have an issue later on not good solvable.., who knows?
Nothing is perfect.

[Patrice Terrier]

Proficient programmers must have several tools at their finger tips, and select the best one to achieve the specific task in the shortest delay.

For large projects, i found that RAD tools + low level specific DLLs are the best combination.

...

[Frederick J. Harris]

Yes, I largely agree with you Edwin.  You made all good points.  In the context of the original poster's question about the value of PowerBASIC though, I think the situation of which I speak has merit in terms of bringing out the plusses and minuses of the different programming tools and development methodologies.

The app of which I speak was originally a mainframe app written in Algol and maintained by a talented individual within my organization for probably over 20 years.  At about the time he transferred to another area of the organization, the company that supported the mainframe was phasing it out, so another app needed to be created, and at the time - around 1997, PCs had developed to the point where a PC application became possible.  It was estimated that it might cost several million to create and it was a big project that lasted several years.   A large outside programming contractor was hired to do the work (a large firm, again I won't mention any names).  Around 2000 the application came into use, and there were continual problems.  It was very slow, it lost data, and was expensive to maintain, as I mentioned.  Interestingly, like .NET, the application ran within an interpreted environment, but it wasn't .NET.

About that time I transferred into the section of the organization that used this application and my role, in addition to developing mobile device data collection software, was to troubleshoot problems with this application and interface with the contract programmers who needed to continually fix bugs, modify features, etc.  There was some overlap in the functionality of this app and some of the support software I had created in Visual Basic to support my data collection software.  When I saw how horrible, slow, and poor the thing was it occurred to me I could probably easily redo that part of it not done by my Visual Basic app and end up with an 'in house' solution that actually worked.  

Long about 2003 I was learning .NET and decided I'd take a crack at some of the database functionality of the thing.  I was making some slow progress and all of a sudden there was an initiative from higher up in my organization to create an 'Enterprise Information Management System' and incorporate our application into that and ditch the failed monstrosity we had been using; write it off as a failure, so to speak.  I and several of my collegues felt it would be a massive waste of more money and we would end up with another clunky hard to use, slow application from another outside contractor.

So I pulled out 'all the stops'; abandoned .NET (I wasn't proficient enough in its use yet) and essentially produced a Visual Basic 6 app as a 'fait accompli' that incorporated all the missing features not part of my other Visual Basic 6 applications we used in support of the data collection software.  Naturally it was very fast and efficient and was tailored to meet our exact business specifications.  This was of course easier for me to do as an 'insider' with intimate knowledge of our business requirements.  The app was heavy into Microsoft database and ActiveX technologies.  When I coded it all that mattered to me was to get it done really fast so as to eliminate the possibility of having our application done as a part of the larger 'Information Management System'.  A lot of my code was real crap but we adopted it and it worked.  It was later in around 2005 that I recoded the whole thing in PowerBASIC.  That code I wrote with 'tender loving care'; really the best I could do (an SDK program), and everyone is well pleased with it.   Just recently I recoded the original Visual Basic 6 (it was started in VB4) part into PowerBASIC too.  All totalled, the thing (which was originally a mainframe app) comes in around 1200K actually (1.2M).  Maybe 50,000 lines of code not counting includes.

Although my original Visual Basic app was heavy into ActiveX database and visual control functionality as was typical for VB apps, I opted for custom controls and low level ODBC Api database access in the PowerBASIC app (still use PB COM for Word and Excel access which is a big part of the app).  Like many PowerBASIC users I found that custom controls in Dlls were an easier route to take than heavy COM components.  Likewise one could end up with smaller apps with fewer dependencies and registry problems.  I like the idea of distributing an app by telling someone to copy an exe and paste it anywhere they like and it will run!  Certainly a far cry from Microsoft stuff which largely relies on heavy duty installation software.  

This PowerBASIC app has had a big positive effect in my organization over and beyond what one might ordinarily think of as programming matters.  Because it runs so fast over the network it has allowed several individuals to actually relocate their home away from our main offices in the capitol of the state.  The older failed app it replaced could take several hours to perform a transaction over the network, and the PowerBASIC app only takes a few seconds (instantaneous if not done accross a network).  So it wasn't really possible to work from remote locations.  

Had I been more proficient in .NET at the time I could have used that to good advantage.  It would have been somewhat slower than the PowerBASIC app, but I'm sure it could have been done.  At the time though I was more interested in going low level than high level because of my personal inclinations I suppose.  I had just survived the trauma of having invested a significant part of my life into Visual Basic and I saw how Microsoft simply abandoned it in favor of an interpreted programming environment.  And then there was Dll h*** and registry problems.  I saw the PowerBASIC solution as a better option.  I have to say though that my organization is big behind .NET.  It is a requirement of all software development projects let out to bid.  We are solid Microsoft except for the anomaly of my PowerBASIC system.  I do not get any static from anyone.  Our IT department (I'm not part of it) ignores me and would prefer to believe I and my system do not exist.  However, they can't argue with success.

When Microsoft abandoned Visual Basic 6 and I found that I disliked .NET so much, I was like many others really rethinking the issue of programming languages.  Since DOS was finally falling by the wayside even in the world of handheld data collectors, I had to use C/C++ Microsoft tools for my programming there.  I was seriously considering using C or C++ for my desktop development work too.  However, I found that I also disliked the Windows Class Frameworks such as MFC that most C++ developers were using for their GUI C++ apps.  Basically, I liked Charles Petzold style Sdk coding in C.  Long about that time (maybe 2002) I discovered I could use that exact style of coding with PowerBASIC.  That's pretty much when I became a true believer in PowerBASIC.  I thought it was incredible I could code exactly the same in C++ or PowerBASIC; the programs were so similiar you had to look close to tell the difference.  What this meant to me was that I didn't really need to learn two different application development paradigms for the two different platforms I had to work with, i.e., Windows CE and desktop Windows.  True, there were two different languages involved, i.e., C++ and PowerBASIC, but using the SDK programming style they were essentially the same.  Anything I learned while coding in Windows CE would transfer directly to my desktop PowerBASIC work and vice - versa.  So there you have  my principal reasons for thinking PowerBASIC is close to the ultimate choice for app development work.  

[Patrice Terrier]

but using the SDK programming style they were essentially the same

And once you understand that, then you become free to move from one language to another or to mix them together!

   

[Edwin Knoppert]

Well, i am not going to reply with such a long text

I wanted to tell you that we did/are made the move from the low-level stuff like Borland and PowerBASIC to .NET.
Coding in c# is easier, the IDE works with you, debugging is a breeze and also we prefer a built-in way to maintain the project (currently sourcesafe but we'll move on).
For myself i started .NET doing ASP.NET using VB but made the move to c# rapidly.
The first year and a half where daunting!
Then a few new people came in and they did c# (and T-SQL) for years and thus i learned a lot from them.
This was a real gain for the company and for me otherwise i doubt we ever got so far as we did right now.

ASP.NET, i know a lot about its technique but i truly(!!!!) hate the html part of it.
I am not a designer, i produce code, it took years before we finally got us a 'html-billy', this combination works, he doesn't know that much of the language and i don't care.
It's a lack of understanding development not to obtain the right people, i can't stress that enough, something that i meant before which may have applied to your situation.

So far i haven't found any speed reducing components in c# itself, many people complain about speed.
Problem is the ASP.NET MSIL being compiled over and over (even precompiled) and the combination of SQL server.
This simply requires the biggest computer imo to make it run propelry, ASP.NET will never run properly!
The language is fine but medium to large projects are a real pain to edit, the IDE is so slow..

Winforms, i haven't dealt with it much but i know it develops slightly better for some reason.
But i mentioned speed in c#, this is truly so, datasources, dictionaries and stringbulders are really fast.
Of course you'll need to learn c# and not think of (byte)pointers as i do in PB but the have alternatives which are really fast.

Main problem is that it is complex, very hard to understand how to combine parts together, i often refer to sending a mail, this requires certain objects but can not be solved unless you look it up online.
No beginner can solve these kind of complexities, they are to 'low-level', simply having a simple mail object where you add attachmentsfiles and all the parts is not what it brings.

In some cases you need to cast objects like during the http context request stuff, how would i know when?
(Unpredictable but these are rare though)

For me PowerBASIC is a dead end, it was all i needed several years ago and currently i am no longer the only person writing those modular includes.
My colleague can program PB if i am not around.
As i see it now a compiler like PB has simply to much options, it should be a bare bones compiler classes included but no DDT stuff, no graphics.
Simply PBDLL6 with classes should do, maybe activex support oh and.. unicode all the way?
Of course it would be hard to keep on selling since there would be no new features.

I will be doing the few PB apps/dlls for several more years but even those are extended with .NET support so more users can maintain that.

As you see, an opposite story and also reasonably succesful.
And let's not forget, i really liked PB and doing pointers and such but if you learn new things older things it may no longer forfill the needs.

[Frederick J. Harris]

I fully understand where you are coming from Edwin.

I believe my reason for taking a low level coding approach using strictly SDK style coding against the Windows Api has more to do with my Windows CE work than anything else, coupled with the fact the material itself is so overpowering in its complexity that there simply isn't enough of me to go around to master both low level Windows Api coding and .NET high level coding.  People often lament about there being no tutorial book written about PowerBASIC from which one could learn the language.  And this is a problem.  However, there is also a thing called 'information overload'; kind of the problem in reverse, and that was the problem for me with .NET.  Too much information and not enough time!  Petzold's recommendation was to sleep less!

Back to Windows CE though, what I had to do there was recreate all my DOS data recorder data collection software in Windows CE.  I imagine most of us here were experts at DOS coding and knew all the tricks to write incredibly efficient programs.  My DOS programs created with QuickBasic & PowerBASIC DOS were designed for very, very, fast high speed data entry of large amounts of field data (tree info).  For example, users never had to hit an [ENTER] key or [TAB] key to move to the next data entry field.  In addition, most of my programs provided for entry in a full screen grid type setup.  Well, trying to recreate something like this in Windows isn't easy.  Not easy at all.  And it had to be done.  My greatest fear once it became clear that we would need to move from DOS to Windows CE was that the folks simply wouldn't use the newer data recorders running funky Windows programs and would revert to paper data entry which is a nightmare.  And this has indeed happened even though I've created Windows CE programs just as easy to use as the DOS ones.  To do that sort of thing though required me to delve pretty deep into the low levels of Windows.  Basically, I create my own edit controls and custom control data entry grids and such.  But what with all that work I guess I found it more efficient for me to use low level coding for everything rather than just Windows CE.  Maybe I'm wrong, but it seems like it would have been more work to master the Windows Api just for Windows CE coding, and master .NET too for desktop work.  And after all, while one amasses many lines of code to do a simple thing using the Api, there is a lot of copy/paste (clipboard inheritance!) involved to ease the task.  I mean, after all, who starts a new Windows program from scratch?

But I wouldn't say I'm totally disinterested in .NET.  I especially like the things you've done in integrating various levels of .NET functionality into your designer, and Jose's work with using .NET components from PowerBASIC is also interesting.  I'd like to have more time to explore that.  What I've found is that I only have so much time to spread around, so I have to pick and choose what I learn to use.  I wish I was smarter that I could pick up stuff faster, but I find that it takes me quite a bit of time to learn these various things.