Ambitious project - comments?

I have about two months of free time coming up and I want to wade into a
programming project I've been thinking about for awhile. Before I say what
I want to do, however, let me say what I have now as background.

I've written an app for my iPAQ 1910's & 1930's that we use here in my
business. It's an OOP Win32 C++ non-MFC app developed with eVC3.0. It
uses ADOCE3.1 to interface with an Access DB (CDB) file. This Access file
transfers to and from my desktop system via ActiveSync 3.8.0. On the
Desktop, I interface with the Access DB (MDB) file via the Microsoft Office
2002 Access program and some VBA code I've written. Also, my desktop
Access file is transferred out to my website where I've written ASP code
that allows users to search my database to see what I have in stock.

All of this works OK. But, there are parts of it that are a pain. For
example, only one copy of my DB can be the 'live' copy at a time. Moving
the 'live' Access DB file to the Desktop causes my desktop's version to
loose its Primary Record Keys and to forget its Relationships. And, as I'm
not the world's best VBA programmer, the tools I've developed on the Desktop
end are a bit rough whereas the stuff I've written on the iPAQ side does
precisely what I want because I've programmed Windows Win32 OOP C++ for
years.

So, this is what I'm thinking:
---------------------------------
(1)
Goal: Replace Access on the PPC side with SQLce.
Assumption: I'll still be able to use ADOCE3.1 to interface with the new
SQLce DB from my current code.
Advantages: I've heard that SQLce is a better tool on the iPAQ.

(2)
Goal: Replace ActiveSync transfers via USB with my own custom
TCP/IP code transfers via 802.11b.
Assumption: None that I know of other than that I'm capable of doing this
(I've done some network programming).
Advantages: With full control over all details of the sync process, I'll be
able to merge DB changes made
on anyone of several PPCs with the desktop DB smoothly.
These syncs will be able to
automatically happen whenever a PPC is within range of
the Desktop's AP. The Desktop version
of the Access DB will stop losing its Primary Record
Keys and forgetting its Relationships because
I'll be updating it record by record in-place rather
than replacing it wholesale with a copy from
the PPC.

(3)
Goal: Cease using the Microsoft Office 2002 Access program and
the VBA tools I've developed to
interface with the DB on the desktop end. Replace
these with a Windows OOP Win32 C++
non-MFC app of my own creation that uses ADO to
interface to the desktop Access DB.
Assumption: None that I know of.
Advantages: This will allow me to interface with the desktop Access file
exactly as I want to.

(4)
Goal: Because I'll be writing a Win32 OOP C++ non-MFC app on the
desktop side, it will be able to
serve both as the sync master coordinator and as my
interface to the desktop version of the DB.
Assumption: None that I know of other than that I'll need to have a good
grip on coding multiple threads
of execution (which I do).
Advantages: A single point of interface on the desktop end customized as I
want.

(5)
Goal: Stay with PPC code development using eVC3.0 rather than
upgrading to later development
environments.
Assumption: That I can do everything I want on the PPC end with my existing
eVC3.0 and ADOCE3.1 tools.
Advantages: I understand this stuff well now and I don't know of anything
in the later development
environments that I really need.

(6)
Goal: Stay with VC++6.0 on the desktop side rather than upgrading
to later development environments.
Assumption: That I can do everything I want on the desktop end using my
existing VC++6.0 tools.
Advantages: I understand this stuff well now and I don't know of anything
in the later development
environments that I really need.
------------------------------------
That's it. There's a lot of parts to this idea and I'm looking for folks
to poke holes in it if they can so I don't have to discover oversights the
hard way later.

Thanks in advance,

Dennis Gallagher
www.woodscreeknursery.com

ctacke/>
Sat Oct 29 08:18:36 CDT 2005

All of it sounds reasonable. My only move would be to use Studio 2005 for
the entire thing because the IDE is just so much easier and nicer to use,
but staying with eVC and VC 6 will also work.

-Chris


"Dennis" <junk@galron.com> wrote in message
news:eonTtIE3FHA.3872@TK2MSFTNGP09.phx.gbl...
>I have about two months of free time coming up and I want to wade into a
> programming project I've been thinking about for awhile. Before I say
> what
> I want to do, however, let me say what I have now as background.
>
> I've written an app for my iPAQ 1910's & 1930's that we use here in my
> business. It's an OOP Win32 C++ non-MFC app developed with eVC3.0. It
> uses ADOCE3.1 to interface with an Access DB (CDB) file. This Access
> file
> transfers to and from my desktop system via ActiveSync 3.8.0. On the
> Desktop, I interface with the Access DB (MDB) file via the Microsoft
> Office
> 2002 Access program and some VBA code I've written. Also, my desktop
> Access file is transferred out to my website where I've written ASP code
> that allows users to search my database to see what I have in stock.
>
> All of this works OK. But, there are parts of it that are a pain. For
> example, only one copy of my DB can be the 'live' copy at a time. Moving
> the 'live' Access DB file to the Desktop causes my desktop's version to
> loose its Primary Record Keys and to forget its Relationships. And, as
> I'm
> not the world's best VBA programmer, the tools I've developed on the
> Desktop
> end are a bit rough whereas the stuff I've written on the iPAQ side does
> precisely what I want because I've programmed Windows Win32 OOP C++ for
> years.
>
> So, this is what I'm thinking:
> ---------------------------------
> (1)
> Goal: Replace Access on the PPC side with SQLce.
> Assumption: I'll still be able to use ADOCE3.1 to interface with the new
> SQLce DB from my current code.
> Advantages: I've heard that SQLce is a better tool on the iPAQ.
>
> (2)
> Goal: Replace ActiveSync transfers via USB with my own custom
> TCP/IP code transfers via 802.11b.
> Assumption: None that I know of other than that I'm capable of doing this
> (I've done some network programming).
> Advantages: With full control over all details of the sync process, I'll
> be
> able to merge DB changes made
> on anyone of several PPCs with the desktop DB
> smoothly.
> These syncs will be able to
> automatically happen whenever a PPC is within range of
> the Desktop's AP. The Desktop version
> of the Access DB will stop losing its Primary Record
> Keys and forgetting its Relationships because
> I'll be updating it record by record in-place rather
> than replacing it wholesale with a copy from
> the PPC.
>
> (3)
> Goal: Cease using the Microsoft Office 2002 Access program and
> the VBA tools I've developed to
> interface with the DB on the desktop end. Replace
> these with a Windows OOP Win32 C++
> non-MFC app of my own creation that uses ADO to
> interface to the desktop Access DB.
> Assumption: None that I know of.
> Advantages: This will allow me to interface with the desktop Access file
> exactly as I want to.
>
> (4)
> Goal: Because I'll be writing a Win32 OOP C++ non-MFC app on
> the
> desktop side, it will be able to
> serve both as the sync master coordinator and as my
> interface to the desktop version of the DB.
> Assumption: None that I know of other than that I'll need to have a good
> grip on coding multiple threads
> of execution (which I do).
> Advantages: A single point of interface on the desktop end customized as I
> want.
>
> (5)
> Goal: Stay with PPC code development using eVC3.0 rather than
> upgrading to later development
> environments.
> Assumption: That I can do everything I want on the PPC end with my
> existing
> eVC3.0 and ADOCE3.1 tools.
> Advantages: I understand this stuff well now and I don't know of anything
> in the later development
> environments that I really need.
>
> (6)
> Goal: Stay with VC++6.0 on the desktop side rather than
> upgrading
> to later development environments.
> Assumption: That I can do everything I want on the desktop end using my
> existing VC++6.0 tools.
> Advantages: I understand this stuff well now and I don't know of anything
> in the later development
> environments that I really need.
> ------------------------------------
> That's it. There's a lot of parts to this idea and I'm looking for folks
> to poke holes in it if they can so I don't have to discover oversights the
> hard way later.
>
> Thanks in advance,
>
> Dennis Gallagher
> www.woodscreeknursery.com
>
>

Dennis
Sat Oct 29 18:33:28 CDT 2005

Chris,

I'm not very familiar with Studio 2005.

- Is this the product that's suppose to be released very soon?
- Using this, I'd be able to generate both code for my PPCs and for my
desktop apps?
- I can generate native Intel code for the desktop sans .NET anything?
- On the PPCs, can I generate code that works for PPC2002 and later
platforms again sans .NET anything?
- Better emulators and better debugging support on the PPCs?

Dennis

"<ctacke/>" <ctacke_AT_OpenNETCF_com> wrote in message
news:uU46euI3FHA.2816@tk2msftngp13.phx.gbl...
> All of it sounds reasonable. My only move would be to use Studio 2005 for
> the entire thing because the IDE is just so much easier and nicer to use,
> but staying with eVC and VC 6 will also work.
>
> -Chris
>
>
> "Dennis" <junk@galron.com> wrote in message
> news:eonTtIE3FHA.3872@TK2MSFTNGP09.phx.gbl...
> >I have about two months of free time coming up and I want to wade into a
> > programming project I've been thinking about for awhile. Before I say
> > what
> > I want to do, however, let me say what I have now as background.
> >
> > I've written an app for my iPAQ 1910's & 1930's that we use here in my
> > business. It's an OOP Win32 C++ non-MFC app developed with eVC3.0. It
> > uses ADOCE3.1 to interface with an Access DB (CDB) file. This Access
> > file
> > transfers to and from my desktop system via ActiveSync 3.8.0. On the
> > Desktop, I interface with the Access DB (MDB) file via the Microsoft
> > Office
> > 2002 Access program and some VBA code I've written. Also, my desktop
> > Access file is transferred out to my website where I've written ASP code
> > that allows users to search my database to see what I have in stock.
> >
> > All of this works OK. But, there are parts of it that are a pain.
For
> > example, only one copy of my DB can be the 'live' copy at a time.
Moving
> > the 'live' Access DB file to the Desktop causes my desktop's version to
> > loose its Primary Record Keys and to forget its Relationships. And, as
> > I'm
> > not the world's best VBA programmer, the tools I've developed on the
> > Desktop
> > end are a bit rough whereas the stuff I've written on the iPAQ side does
> > precisely what I want because I've programmed Windows Win32 OOP C++ for
> > years.
> >
> > So, this is what I'm thinking:
> > ---------------------------------
> > (1)
> > Goal: Replace Access on the PPC side with SQLce.
> > Assumption: I'll still be able to use ADOCE3.1 to interface with the new
> > SQLce DB from my current code.
> > Advantages: I've heard that SQLce is a better tool on the iPAQ.
> >
> > (2)
> > Goal: Replace ActiveSync transfers via USB with my own custom
> > TCP/IP code transfers via 802.11b.
> > Assumption: None that I know of other than that I'm capable of doing
this
> > (I've done some network programming).
> > Advantages: With full control over all details of the sync process, I'll
> > be
> > able to merge DB changes made
> > on anyone of several PPCs with the desktop DB
> > smoothly.
> > These syncs will be able to
> > automatically happen whenever a PPC is within range
of
> > the Desktop's AP. The Desktop version
> > of the Access DB will stop losing its Primary Record
> > Keys and forgetting its Relationships because
> > I'll be updating it record by record in-place rather
> > than replacing it wholesale with a copy from
> > the PPC.
> >
> > (3)
> > Goal: Cease using the Microsoft Office 2002 Access program
and
> > the VBA tools I've developed to
> > interface with the DB on the desktop end. Replace
> > these with a Windows OOP Win32 C++
> > non-MFC app of my own creation that uses ADO to
> > interface to the desktop Access DB.
> > Assumption: None that I know of.
> > Advantages: This will allow me to interface with the desktop Access file
> > exactly as I want to.
> >
> > (4)
> > Goal: Because I'll be writing a Win32 OOP C++ non-MFC app on
> > the
> > desktop side, it will be able to
> > serve both as the sync master coordinator and as my
> > interface to the desktop version of the DB.
> > Assumption: None that I know of other than that I'll need to have a good
> > grip on coding multiple threads
> > of execution (which I do).
> > Advantages: A single point of interface on the desktop end customized as
I
> > want.
> >
> > (5)
> > Goal: Stay with PPC code development using eVC3.0 rather than
> > upgrading to later development
> > environments.
> > Assumption: That I can do everything I want on the PPC end with my
> > existing
> > eVC3.0 and ADOCE3.1 tools.
> > Advantages: I understand this stuff well now and I don't know of
anything
> > in the later development
> > environments that I really need.
> >
> > (6)
> > Goal: Stay with VC++6.0 on the desktop side rather than
> > upgrading
> > to later development environments.
> > Assumption: That I can do everything I want on the desktop end using my
> > existing VC++6.0 tools.
> > Advantages: I understand this stuff well now and I don't know of
anything
> > in the later development
> > environments that I really need.
> > ------------------------------------
> > That's it. There's a lot of parts to this idea and I'm looking for
folks
> > to poke holes in it if they can so I don't have to discover oversights
the
> > hard way later.
> >
> > Thanks in advance,
> >
> > Dennis Gallagher
> > www.woodscreeknursery.com
> >
> >
>
>

The
Mon Oct 31 01:10:19 CST 2005

> - On the PPCs, can I generate code that works for PPC2002 and later
> platforms again sans .NET anything?

no, VS2005 only supports Pocket PC 2003 and later.

for earlier, you need eVC++ 3.0 or 4.0

Dennis
Mon Oct 31 13:38:47 CST 2005

After several days of thinking about this 'ambitious project' and
considering folk's comments, I think I'm going to modify and trim down my
plan as follows:

(1) On the PDA end, I thinking I'm going to stay with eVC++3.0 for
development of my PDA app now that I know VS2005 won't let me generate
PPC2002 code (though it will do PPC2003). I believe that whatever I
develop with eVC++3.0 will migrate forward onto the newer PDAs.

- One side issue I've just thought of is that on the newer PDAs, I'd like to
detect and take advantage of the new screen formats like vertical vs.
horizontal and std vs. VGA resolutions. Any reason why code generated
under eVC++3.0 shouldn't be able to detect and deal with such stuff?

(2) Also, on the PDA end, I'm thinking I don't need to switch to SQLce.
I've noticed that when I upgraded my PDA from my original iPAQ1910's to an
iPAQ 1930 with a faster processor, my DB processing delays dropped into the
barely perceptible range. I know the newer PDAs like the Axim X50v I've
just bought will make the issue of perceptible delays utterly moot.

(3) On the desktop side, I'm thinking that I'll stay with my office suite
and Access 2002. SQL server or MySQL will both cost me money and I can't
see that they'll provide anything I need at this point.

(4) On the desktop side, my problems with ActiveSync will go away because
I'm going to drop it in favor of writing my own WiFi network synchronization
code to keep the desktop and PDA copies of Access aligned correctly.

(5) On the desktop side, my problems with using VBA and Access to interface
with my Access DB will go away because I'm going to write a Windows Win32
C++ non-MFC app (my desktop app) which will interface with the Access DB via
ADO and I'll present everything I need to the user via this program.

- Any comments and/or criticisms of the above would be much appreciated.

- Something new I'm thinking about is the possibility of sharing common
source code between my PDA app and my Desktop app. Most of what these two
apps will do is extremely similar. They will use ADO and ADOCE to
interface with Access and PocketAccess. The data displays will be the same
except for screen format/size. One the PDA, I'll interface using a Stylus
whereas on the Desktop, I'll interface with mouse and keyboard. And,
finally, both apps will contain independent threads which will deal in the
background with WiFi synchronization.

Your thoughts would be most appreciated.

Dennis Gallagher
www.woodscreeknursery.com


"The PocketTV Team" <support@pockettv.com> wrote in message
news:OLDCloe3FHA.4076@TK2MSFTNGP15.phx.gbl...
> > - On the PPCs, can I generate code that works for PPC2002 and later
> > platforms again sans .NET anything?
>
> no, VS2005 only supports Pocket PC 2003 and later.
>
> for earlier, you need eVC++ 3.0 or 4.0
>
>

r_z_aret
Tue Nov 01 13:03:18 CST 2005

On Mon, 31 Oct 2005 11:38:47 -0800, "Dennis" <junk@galron.com> wrote:

>After several days of thinking about this 'ambitious project' and
>considering folk's comments, I think I'm going to modify and trim down my
>plan as follows:
>
>(1) On the PDA end, I thinking I'm going to stay with eVC++3.0 for
>development of my PDA app now that I know VS2005 won't let me generate
>PPC2002 code (though it will do PPC2003). I believe that whatever I
>develop with eVC++3.0 will migrate forward onto the newer PDAs.
>
>- One side issue I've just thought of is that on the newer PDAs, I'd like to
>detect and take advantage of the new screen formats like vertical vs.
>horizontal and std vs. VGA resolutions. Any reason why code generated
>under eVC++3.0 shouldn't be able to detect and deal with such stuff?

My apps check screen dimensions, then resize and position dialog boxes
and controls accordingly. I usually do this in response to WM_SIZE
messages. I created my own application primarily for this purpose; it
was a bit of work to set up, but well worth it. So I don't need to
deal with platform-specific dimension indicators. And my apps built
with the Pocket PC SDK definitely run on Pocket PC 2003, and should
run on WM5. I can't share a lot of my code, but have posted my
Maximize function at least once.


clip


>
>- Something new I'm thinking about is the possibility of sharing common
>source code between my PDA app and my Desktop app. Most of what these two
>apps will do is extremely similar. They will use ADO and ADOCE to
>interface with Access and PocketAccess. The data displays will be the same
>except for screen format/size. One the PDA, I'll interface using a Stylus
>whereas on the Desktop, I'll interface with mouse and keyboard. And,
>finally, both apps will contain independent threads which will deal in the
>background with WiFi synchronization.

When I started my current project (and job), I insisted on using
common code as much as possible. Mainly because I can do most of my
debugging under "big" Windows. On that basis alone, I have been _very_
happy with my choice

Shared code also means that bugs found and fixed on one platform may
well be fixed on other platforms at the same time.

I've also found that each compiler finds different bugs in my code. So
sharing the same code across platforms means subjecting it to
different compilers, and thus another way to find bugs.

I've had to be careful about features, etc. found on one system but
not another. But my apps really don't need much of the fancy stuff. So
> 80% of my code is shared. And most of the differences are handled by
my library, so my application code has even fewer #ifdefs. The biggest
challenge has been the Pocket PC menus.



>
>Your thoughts would be most appreciated.
>
>Dennis Gallagher
>www.woodscreeknursery.com
>
>
>"The PocketTV Team" <support@pockettv.com> wrote in message
>news:OLDCloe3FHA.4076@TK2MSFTNGP15.phx.gbl...
>> > - On the PPCs, can I generate code that works for PPC2002 and later
>> > platforms again sans .NET anything?
>>
>> no, VS2005 only supports Pocket PC 2003 and later.
>>
>> for earlier, you need eVC++ 3.0 or 4.0
>>
>>
>

-----------------------------------------
To reply to me, remove the underscores (_) from my email address (and please indicate which newsgroup and message).

Robert E. Zaret, eMVP
PenFact, Inc.
20 Park Plaza, Suite 478
Boston, MA 02116
www.penfact.com

WillsonSantoso
Wed Nov 02 19:05:02 CST 2005

Dennis,

Upgrading to SQL Server on the desktop would allow you to set up SQL
replication with SQL CE on the devices. This can automatically handles the
data sync, conflict detection etc and allow you to easily have multiple
copies of live database. If having only one 'live' version is a big problem
for you then it may be worth the upgrade.

Regards,
Willson

"Dennis" wrote:

> After several days of thinking about this 'ambitious project' and
> considering folk's comments, I think I'm going to modify and trim down my
> plan as follows:
>
> (1) On the PDA end, I thinking I'm going to stay with eVC++3.0 for
> development of my PDA app now that I know VS2005 won't let me generate
> PPC2002 code (though it will do PPC2003). I believe that whatever I
> develop with eVC++3.0 will migrate forward onto the newer PDAs.
>
> - One side issue I've just thought of is that on the newer PDAs, I'd like to
> detect and take advantage of the new screen formats like vertical vs.
> horizontal and std vs. VGA resolutions. Any reason why code generated
> under eVC++3.0 shouldn't be able to detect and deal with such stuff?
>
> (2) Also, on the PDA end, I'm thinking I don't need to switch to SQLce.
> I've noticed that when I upgraded my PDA from my original iPAQ1910's to an
> iPAQ 1930 with a faster processor, my DB processing delays dropped into the
> barely perceptible range. I know the newer PDAs like the Axim X50v I've
> just bought will make the issue of perceptible delays utterly moot.
>
> (3) On the desktop side, I'm thinking that I'll stay with my office suite
> and Access 2002. SQL server or MySQL will both cost me money and I can't
> see that they'll provide anything I need at this point.
>
> (4) On the desktop side, my problems with ActiveSync will go away because
> I'm going to drop it in favor of writing my own WiFi network synchronization
> code to keep the desktop and PDA copies of Access aligned correctly.
>
> (5) On the desktop side, my problems with using VBA and Access to interface
> with my Access DB will go away because I'm going to write a Windows Win32
> C++ non-MFC app (my desktop app) which will interface with the Access DB via
> ADO and I'll present everything I need to the user via this program.
>
> - Any comments and/or criticisms of the above would be much appreciated.
>
> - Something new I'm thinking about is the possibility of sharing common
> source code between my PDA app and my Desktop app. Most of what these two
> apps will do is extremely similar. They will use ADO and ADOCE to
> interface with Access and PocketAccess. The data displays will be the same
> except for screen format/size. One the PDA, I'll interface using a Stylus
> whereas on the Desktop, I'll interface with mouse and keyboard. And,
> finally, both apps will contain independent threads which will deal in the
> background with WiFi synchronization.
>
> Your thoughts would be most appreciated.
>
> Dennis Gallagher
> www.woodscreeknursery.com
>
>
> "The PocketTV Team" <support@pockettv.com> wrote in message
> news:OLDCloe3FHA.4076@TK2MSFTNGP15.phx.gbl...
> > > - On the PPCs, can I generate code that works for PPC2002 and later
> > > platforms again sans .NET anything?
> >
> > no, VS2005 only supports Pocket PC 2003 and later.
> >
> > for earlier, you need eVC++ 3.0 or 4.0
> >
> >
>
>
>