Another New Trick Under Windows 7/8

On 1/25/2014, Char Jackson posted:
Writing code is a real activity, believe it or not.

Of course I believe it! I've been playing around in that area on and
off
since early 1983, although I only got paid for about an 18-month
stretch in
2008-2009. The rest of the time it has only been a hobby.

If one didn't know how things worked, he'd have trouble writing
code to
the API.

Of course, it's true that if one *did* know how things worked, he'd
*still* have trouble writing code to the API. The voice of
experience
speaks :-)

A lot depends on how well the documented API behavior matches
reality.

Even when the documents do match reality, Windows API programming is
pretty complicated. And actually the texts I used were pretty good.

For me the real irony was that after being out of work long enough to
get A's in both Windows programming and C++ programming, I got a job
where I was programming and solving bugs in a non-Windows system using
Pascal, C, and 68000 assembly language, cross-compiling in Unix for a
proprietary target machine. Never got to write Windows programs
professionally, but I got paid at that job and it was fun, if
occasionally too challenging.

It was so challenging because the code was *huge*, badly written (even
badly laid out on the page), and undocumented, and we didn't even have
real test machines to debug on.

--
Gene E. Bloch (Stumbling Bloch)

On Sun, 26 Jan 2014 15:39:24 -0800, Gene E. Bloch
wrote:

On 1/25/2014, Char Jackson posted:
Writing code is a real activity, believe it or not.

Of course I believe it! I've been playing around in that area on and
off
since early 1983, although I only got paid for about an 18-month
stretch in
2008-2009. The rest of the time it has only been a hobby.

If one didn't know how things worked, he'd have trouble writing
code to
the API.

Of course, it's true that if one *did* know how things worked, he'd
*still* have trouble writing code to the API. The voice of
experience
speaks :-)

A lot depends on how well the documented API behavior matches
reality.

Even when the documents do match reality, Windows API programming is
pretty complicated. And actually the texts I used were pretty good.

For me the real irony was that after being out of work long enough to
get A's in both Windows programming and C++ programming, I got a job
where I was programming and solving bugs in a non-Windows system using
Pascal, C, and 68000 assembly language, cross-compiling in Unix for a
proprietary target machine. Never got to write Windows programs
professionally, but I got paid at that job and it was fun, if
occasionally too challenging.

It was so challenging because the code was *huge*, badly written (even
badly laid out on the page), and undocumented, and we didn't even have
real test machines to debug on.

You were in much deeper than I was. I wrote the engine for a commercial BBS
terminal program in 6502 Assembly in the early 1980's, and the next time I
worked for pay in the programming field I used VB6. No Pascal, C, or 68k
Assembly for me.

--

Char Jackson

On 1/25/2014 6:45 PM, Gene E. Bloch wrote:
On 1/24/2014, Char Jackson posted:
On Fri, 24 Jan 2014 17:49:06 -0800, Gene E. Bloch
wrote:

On 1/24/2014, Gene E. Bloch posted:
On 1/24/2014, Char Jackson posted:
On Thu, 23 Jan 2014 11:28:50 -0700, Ken Blake
wrote:

On Wed, 22 Jan 2014 21:39:49 -0800, Gene E. Bloch
wrote:


In the books I've used and the course I took, it was emphasized
that everything you see on screen is a window. That's not well
phrased...

What I mean is that we tend to think of that whole large object
occupying a big part of the screen as *the* window - but all the
buttons and drop-down boxes and what-have-you objects in that
window are all considered to be windows as well. They are
windows within windows within windows...


I guess, as with so many things, that terminology varies with who's
using it. Personally, I completely disagree with that statement.

As a starter, desktop icons and icons elsewhere, such as on the task
bar, are not Windows to me. And things like dialog boxes, drop-down
lists, error messages, etc. although much more window-like than
icons, are not usually considered to be Windows either.
Ditto!

But you guys are civilians...

Seriously? You had to drop the C-word? ;-)


And now I'll have recourse to the horse's mouth:

http://msdn.microsoft.com/en-us/libr...=vs.85%29.aspx


From that page, not even very far down:
"If you are new to Windows programming, it may surprise you that UI
controls, such as buttons and edit boxes, are themselves windows."

Yeah, well, what do you expect Microsoft to say? When the toolbox only
contains a hammer, everything looks like a nail.

Out here in the real world, we know the difference.

Writing code is a real activity, believe it or not.

If one didn't know how things worked, he'd have trouble writing code to
the API.

Of course, it's true that if one *did* know how things worked, he'd
*still* have trouble writing code to the API. The voice of experience
speaks :-)

The real problem I see with windows is that they are not always equal.
Some can be re-sized, some scrolled via the side bar and bottom bar,
others not.

"charlie" wrote:

The real problem I see with windows is that they are not always equal.
Some can be re-sized, some scrolled via the side bar and bottom bar,
others not.

Those fetures are controlled by the programmer responsible for the code that
creates and manages the window.

When you write an application that displays a window you set options that
control what elements and capabilities are enabled; if you aren't happy with
the inability to resize (or whatever) a window that's not a restriction
imposed by Windows; it's only one that Windows offered and which was used by
the programmer.

And yes, I also get irritated at windows (or at least controls within
windows [lower-case "w"]) that should be resizable or scrollable but aren't,
especially when they truncate a text string I need to see.

Joe

On 1/26/2014, Char Jackson posted:
On Sun, 26 Jan 2014 15:39:24 -0800, Gene E. Bloch
wrote:

On 1/25/2014, Char Jackson posted:
Writing code is a real activity, believe it or not.
Of course I believe it! I've been playing around in that area on
and off
since early 1983, although I only got paid for about an 18-month
stretch in
2008-2009. The rest of the time it has only been a hobby.
If one didn't know how things worked, he'd have trouble writing
code to
the API.

Of course, it's true that if one *did* know how things worked,
he'd *still* have trouble writing code to the API. The voice of
experience
speaks :-)

A lot depends on how well the documented API behavior matches
reality.

Even when the documents do match reality, Windows API programming is
pretty complicated. And actually the texts I used were pretty good.

For me the real irony was that after being out of work long enough
to get A's in both Windows programming and C++ programming, I got a
job where I was programming and solving bugs in a non-Windows
system using Pascal, C, and 68000 assembly language,
cross-compiling in Unix for a proprietary target machine. Never got
to write Windows programs professionally, but I got paid at that
job and it was fun, if occasionally too challenging.

It was so challenging because the code was *huge*, badly written
(even badly laid out on the page), and undocumented, and we didn't
even have real test machines to debug on.

You were in much deeper than I was. I wrote the engine for a
commercial BBS terminal program in 6502 Assembly in the early 1980's,
and the next time I worked for pay in the programming field I used
VB6. No Pascal, C, or 68k Assembly for me.

I worked in programming for about 38 years, 35 or 36 where programming
or software engineering was my job designation; I had exposure to lots
of stuff...

And I still do a tiny bit for fun (fun?). Only little things for my own
entertainment or use.

The most recent was a program to display the phone number on an Android
phone, where the owner of the phone couldn't remember her number and
where it takes about 27 obscure touches to get it natively. It now
takes her one touch to bring it up and one to dismiss it.

Other than the user interface infrastructure, the executable code is
about 12 lines - including formatting the output the way the user
likes it.

It was a *big* job :-)

--
Gene E. Bloch (Stumbling Bloch)

On 1/27/2014, Joe Morris posted:
"charlie" wrote:

The real problem I see with windows is that they are not always
equal.
Some can be re-sized, some scrolled via the side bar and bottom
bar, others not.

Those fetures are controlled by the programmer responsible for the
code that creates and manages the window.

When you write an application that displays a window you set options
that control what elements and capabilities are enabled; if you
aren't happy with the inability to resize (or whatever) a window
that's not a restriction imposed by Windows; it's only one that
Windows offered and which was used by the programmer.

And yes, I also get irritated at windows (or at least controls within
windows [lower-case "w"]) that should be resizable or scrollable but
aren't, especially when they truncate a text string I need to see.

Joe

+1 for the whole post.

--
Gene E. Bloch (Stumbling Bloch)

Gene E. Bloch wrote:

The most recent was a program to display the phone number on an Android
phone, where the owner of the phone couldn't remember her number and
where it takes about 27 obscure touches to get it natively. It now takes
her one touch to bring it up and one to dismiss it.

I put my phone number in my contacts list. Easy to find.

On 1/27/2014, Henry posted:
Gene E. Bloch wrote:

The most recent was a program to display the phone number on an
Android phone, where the owner of the phone couldn't remember her
number and where it takes about 27 obscure touches to get it
natively. It now takes her one touch to bring it up and one to
dismiss it.

I put my phone number in my contacts list. Easy to find.

Not by a long shot as easy as with the program I gave her.

When you're on a phone call and someone asks you for your number, it's
not very user-friendly to have to (1) find the contacts (where her
phone number was, of course, already listed), and (2) navigate through
them.

Other phones in our experience had the phone number in the notification
bar, always readily available. My method is not as easy as that.

--
Gene E. Bloch (Stumbling Bloch)

In article , lid
says...

On 1/26/2014, Char Jackson posted:
On Sun, 26 Jan 2014 15:39:24 -0800, Gene E. Bloch
wrote:

On 1/25/2014, Char Jackson posted:
Writing code is a real activity, believe it or not.
Of course I believe it! I've been playing around in that area on
and off
since early 1983, although I only got paid for about an 18-month
stretch in
2008-2009. The rest of the time it has only been a hobby.
If one didn't know how things worked, he'd have trouble writing
code to
the API.

Of course, it's true that if one *did* know how things worked,
he'd *still* have trouble writing code to the API. The voice of
experience
speaks :-)

A lot depends on how well the documented API behavior matches
reality.

Even when the documents do match reality, Windows API programming is
pretty complicated. And actually the texts I used were pretty good.

For me the real irony was that after being out of work long enough
to get A's in both Windows programming and C++ programming, I got a
job where I was programming and solving bugs in a non-Windows
system using Pascal, C, and 68000 assembly language,
cross-compiling in Unix for a proprietary target machine. Never got
to write Windows programs professionally, but I got paid at that
job and it was fun, if occasionally too challenging.

It was so challenging because the code was *huge*, badly written
(even badly laid out on the page), and undocumented, and we didn't
even have real test machines to debug on.

You were in much deeper than I was. I wrote the engine for a
commercial BBS terminal program in 6502 Assembly in the early 1980's,
and the next time I worked for pay in the programming field I used
VB6. No Pascal, C, or 68k Assembly for me.

I worked in programming for about 38 years, 35 or 36 where programming
or software engineering was my job designation; I had exposure to lots
of stuff...

And I still do a tiny bit for fun (fun?). Only little things for my own
entertainment or use.

I'm willing to bet you used some libraries then as surely going directly
at the OS's API level takes a little more effort.

Note : I'm basing this on using something like Delphi and it's objects
etc. under Windows compared to writing straight C (or Pascal etc.) that
goes right at the Windows API. As an example, in Delphi I basically
don't have to write a line of code to create the main window that will
max/min and close using right top icons on window title. Going straight
at Windows API takes multipule lines of code spread across a couple of
routines, declaring structures, filling that structure with required
info, "submit" that to get a handle, set up message loop and message
handler routines etc. etc.

On 1/28/2014, pjp posted:
I'm willing to bet you used some libraries then as surely going
directly
at the OS's API level takes a little more effort.

Note : I'm basing this on using something like Delphi and it's
objects
etc. under Windows compared to writing straight C (or Pascal etc.)
that
goes right at the Windows API. As an example, in Delphi I basically
don't have to write a line of code to create the main window that
will
max/min and close using right top icons on window title. Going
straight
at Windows API takes multipule lines of code spread across a couple
of
routines, declaring structures, filling that structure with required
info, "submit" that to get a handle, set up message loop and message
handler routines etc. etc.

I'm not sure I understand your post.

Of course I used the Windows API for programming in Windows and the
Android API for programming in Android. To do otherwise would be very
difficult, and not only would it reinvent an already invented - and
very complicated - wheel, it would also create code that no one else
could read (for that matter, it would probably be code that *I*
couldn't read later!).

Anyway, the Windows coding I did was not with a GDI, it was with
explicit lines of code. To create a window, I would call an API
function to create a window, then use the resulting handle in other
calls to manipulate that window or to add subwindows such as buttons
and so on.

In Android, it's a bit different. I don't really use a graphic GDI,
such as I used to write Basic programs on a Palm or on a PC. Instead I
describe the windows and other controls in XML files, where you just
say "text box, so big, numbers only" and so on. Then the compiler
converts those descriptions into code. But it's still not exactly a
piece of cake, since for one thing, I haven't done enough of that to
make it second nature. For another, there are many kinds of items and
many parameters involved. And I'm not even addressing the documentation
here :-)

Even in programming in C under Unix terminals, I rarely used direct OS
calls, nor did anyone else. We used the functions provided in the C
library, such as fopen, fwrite, getchar, toupper, and so on.

To get a feel for the complexity of Windows programming, look at this:

http://msdn.microsoft.com/en-us/libr...=vs.85%29.aspx

and browse into one - or several - of the many topics thereunder.

Here's one fairly simple example, to enable or disable a button:

http://msdn.microsoft.com/en-us/libr...=vs.85%29.aspx

where, among other things, you can see this:

"hwndCtl

Type: HWND

A handle to the button control."

which, if you're familiar with Windows development, shows you that the
button control is identified by a window handle, and so it is...a
window!

--
Gene E. Bloch (Stumbling Bloch)