(I'm on 7, but the problem applies to XP and 10 too, and the solution -
if there is one! - may be universal.)

Occasionally, I accidentally either move a window, or drag one of its
sides, by mistake - while doing (or intending to) something else with
the mouse pointer, it catches on an edge, or more likely a title bar.
(Unlike a lot of people, I _don't_ operate most of my windows
full-screen most of the time, so their relative sizes and positions are
important to me.)

I discovered fairly recently that _if I notice while the movement is in
process_ (I just see the _outline_ move, i. e. I've still got the "mouse
button pressed" [actually I use a touchpad, but similar applies]), I can
cancel the move/resize by - keeping the button pressed and - pressing
the Esc key. But if I don't - anyone know of a way of undoing a window
move/resize? (Ctrl-Z doesn't seem to work.)
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

to sing like an injured seagull takes real skill. - Andrew Collins on Meryl
Streep as Florence Foster Jenkins, RT 2018/8/4-10

"J. P. Gilliver (John)" <G6JPG@255soft.uk> wrote

| I discovered fairly recently that _if I notice while the movement is in
| process_ (I just see the _outline_ move, i. e. I've still got the "mouse
| button pressed" [actually I use a touchpad, but similar applies]), I can
| cancel the move/resize by - keeping the button pressed and - pressing
| the Esc key. But if I don't - anyone know of a way of undoing a window
| move/resize? (Ctrl-Z doesn't seem to work.)

Seems very unlikely. Move and resize are not up to
Windows. Programs handle it. A program may remember
where it was last and resume that position if the window
has been minimized or the program closed. But that's
up to the program author to write the code for storing
coordinates and then retrieving the data.

I've never heard of an Undo.
That would require a program to store an undo history of
window coordinates, on the off chance that someday,
someone would care. If they went to that trouble then also,
of course, there would be a menu item, such as View ->
Last Window Position.

On Mon, 23 May 2022 at 08:13:58, Mayayana <mayayana@invalid.nospam>
wrote (my responses usually FOLLOW):
[]
> Seems very unlikely. Move and resize are not up to
>Windows. Programs handle it. A program may remember

Interesting point.

>where it was last and resume that position if the window
>has been minimized or the program closed. But that's
>up to the program author to write the code for storing
>coordinates and then retrieving the data.

Now you mention it, they _do_ remember (their position and size) when
minimised - or maximised for that matter. (At least, I can't think for
the moment of one that doesn't [obviously some have a fixed size].)
>
> I've never heard of an Undo.
>That would require a program to store an undo history of
>window coordinates, on the off chance that someday,

Well, only one would be needed, not a full history. And a we've just
discussed - though I hadn't thought about it until we did - they _do_
remember that through a minimise/maximise followed by a restore. Or
something does - might be Windows.

>someone would care. If they went to that trouble then also,
>of course, there would be a menu item, such as View ->
>Last Window Position.
>
I agree, I've never seen that. Though not that it'd need a full menu
entry.
>
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

Never be led astray onto the path of virtue.

On 5/23/22 08:35, this is what J. P. Gilliver (John) wrote:
> On Mon, 23 May 2022 at 08:13:58, Mayayana <mayayana@invalid.nospam> wrote (my responses usually FOLLOW):
> []
>> Seems very unlikely. Move and resize are not up to
>> Windows. Programs handle it. A program may remember
>
> Interesting point.
>
>> where it was last and resume that position if the window
>> has been minimized or the program closed. But that's
>> up to the program author to write the code for storing
>> coordinates and then retrieving the data.
>
> Now you mention it, they _do_ remember (their position and size) when minimised - or maximised for that matter. (At
> least, I can't think for the moment of one that doesn't [obviously some have a fixed size].)
>>
>>    I've never heard of an Undo.
>> That would require a program to store an undo history of
>> window coordinates, on the off chance that someday,
>
> Well, only one would be needed, not a full history. And a we've just discussed - though I hadn't thought about it until
> we did - they _do_ remember that through a minimise/maximise followed by a restore. Or something does - might be Windows.
>
>> someone would care. If they went to that trouble then also,
>> of course, there would be a menu item, such as View ->
>> Last Window Position.
>>
> I agree, I've never seen that. Though not that it'd need a full menu entry.
>>
I've found that cntl-Z, the undo for text editing will sometimes undo a file copy. At least it does on Linux, might be
worth trying on you window move/resize.

Al

On Mon, 23 May 2022 at 08:44:12, Big Al <Bears@invalid.com> wrote (my
responses usually FOLLOW):
[]
>I've found that cntl-Z, the undo for text editing will sometimes undo a
>file copy. At least it does on Linux, might be worth trying on you
>window move/resize.
>
>Al

It certainly does undo a move in Windows - at least to another location
on the same partition; I haven't tried it on a move between
partitions/drives or on a copy. It undoes a rename, too. In both cases,
only if fairly soon after the move/rename - I don't mean in time, but in
other actions. But unfortunately it doesn't for window move/resize.

Assuming Linux has a similar facility for moving/resizing windows (by
dragging the title bar or edges), does ^Z work there?
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

Quantum particles: the dreams that stuff is made of - David Moser

"J. P. Gilliver (John)" <G6JPG@255soft.uk> wrote

| they _do_
| remember that through a minimise/maximise followed by a restore. Or
| something does - might be Windows.
|

No, that's what I'm saying. I write software. If I don't track and
store window positions then windows will typically come up in
the upper left, because that's the coordinates 0,0. But nearly all
programs are designed to track their window positions. I code mine
to open center-screen unless I have last-opened coordinates. Then
I use those. Some programs do other things. Firefox, for example,
seems to check open instances and display multiple windows in
cascade fashion.

| >someone would care. If they went to that trouble then also,
| >of course, there would be a menu item, such as View ->
| >Last Window Position.
| >
| I agree, I've never seen that. Though not that it'd need a full menu
| entry.

You might not need it. You might be happy with Ctrl + Alt + 1 or
some such. But then people can't do it with a mouse and there's no
way to advertise the functionality. It would be very dumb to go
to the trouble to code a window position history, when only some
guy in England wants it. It would be far more dumb to go to that
trouble and then not advertise the functionality through the menu.
No one would ever find out about it! You could put it in the help,
but ono one reads help. The general public lives in a mindset of
TL;DR. Will it fill my stomach or give me an orgasm? Then TL;DR.

There's tradition, though MS have broken a lot of their
own rules in recent years. But the general idea is to put things on
the menu, also put it on the context menu if appropriate, and at least
for standard operations like Copy, also implement standard shortcuts
like Ctrl + C. But those are left over from DOS days. Most people
don't know about them and they're not discoverable.

I use context menu whenever possible, almost never using
keyboard shortcuts, but I have noticed that in
some older programs, like Paint Shop Pro 5, context menu wasn't
implemented, despite the menu listing keyboard shortcuts for most things.
So I guess the historical development was keyboard in DOS, which was
then carried over to Windows for compatibility. Then in Windows, having
a GUI, a menu was introduced. Then perhaps only later, context menu
was made standard.

But even that can vary. One especially maddening detail for me is
Cut and Copy. Those operations should cut or copy the selected
text in the window where text is selected. That text window is the
context. But in some programs, the right-click must be done exactly
on top of the selected text. If it isn't, the right click is treated as a
left click, unselecting all text!

J. P. Gilliver (John) wrote:

> (I'm on 7, but the problem applies to XP and 10 too, and the solution -
> if there is one! - may be universal.)
>
> Occasionally, I accidentally either move a window, or drag one of its
> sides, by mistake - while doing (or intending to) something else with
> the mouse pointer, it catches on an edge, or more likely a title bar.
> (Unlike a lot of people, I _don't_ operate most of my windows
> full-screen most of the time, so their relative sizes and positions are
> important to me.)
>
> I discovered fairly recently that _if I notice while the movement is in
> process_ (I just see the _outline_ move, i. e. I've still got the "mouse
> button pressed" [actually I use a touchpad, but similar applies]), I can
> cancel the move/resize by - keeping the button pressed and - pressing
> the Esc key. But if I don't - anyone know of a way of undoing a window
> move/resize? (Ctrl-Z doesn't seem to work.)

You already know about using the Esc key to abort the operation while it
is *in progress* (the mouse button is still pressed when Esc is hit).
That the window is getting moved or resized should be obvious before you
release the mouse button hence the Esc key is how you abort a
noncommitted operation. As Maya notes, there is no Undo (Ctrl+Z) for a
move/size operation after the operation has been committed. Too late
after releasing the mouse. Once you see the window resizing or moving,
do NOT release the mouse button! With a pending operation, you can
Esc(ape) it. When you have an Oops, keep the mouse button pressed to
let you un-Oops.

You have to break the habit of releasing the mouse button to afterward
seek how to revert the move or resize of a window. Don't release until
you're satisfied with the change, and don't release if you want to use
Esc to abort. Instinct has you back off (release).

Personally I don't rely on absolute positioning or sizing to stay fixed
for windows. Too many times when loading an app, the window opens
somewhere else than before. You cannot guarantee the window will always
open in the same spot unless the program itself lets you configure its
initial X-Y coordinates for the upper left corner along with size (which
could still run into a problem if the screen size is smaller than the
program's fixed window size). Plus, even if a program gave you that
option, it would only get enforced when the program's window was opened,
not prevent you later from moving or resizing that window. Trying to
load windows always in the same spot and always with the same size is an
exercise in futility if the program doesn't track a location history
even if just one history entry of where was the window and its size when
the window was last closed.

If you want windows to always open in the same spot, you need something
more for window management than Windows affords to the end user, like a
better window manager. I've heard of, but not used Desksoft's
WindowManager (https://www.desksoft.com/WindowManager.htm). I'm sure I
could find other window managers if I bothered to hunt for them. That
window manager lets you configure where a window opens (don't know about
sizing), and even lock the window so it cannot be moved or resized.
I've also heard of, but not used, ShellFolderFix
(https://www.majorgeeks.com/files/details/shellfolderfix.html).
ShellFolderFix works with some programs (Firefox, LibreOffice, Revo
Uninstaller), but not with some other programs (Thunderbird, CCleaner,
Irfanview). Up to you to discover with which program's window it can
manage their positioning.

Another option is to use a hotkey macro tool, like AutoHotkey or AutoIt,
that can position a window to a fixed coordinate for the upper left
corner and set a size on the window. You'd define a single hotkey that
has multiple rules depending on the titlebar's string (window name), and
each rule or condition would position that window for that program at
the same spot. I haven't used AutoHotkey for many years, but recall it
can interrogate the string for the titlebar, and it could position and
size the window. You'd have to define multiple conditions, or tests, in
the macro that would set position and size based on the titlebar. Alas,
many programs use the same titlebar string for multiple window opens by
the same program, so there's no way to distinguish one program's window
from another that it opened.

In a similar vein of using a macro with multiple conditions to test on
the titlebar string for where to position and size the currently focused
window, looks like WinSize2 can do that for you; see
http://winsize2.sourceforge.net/en/index.htm. Instead of having to
write a script with multiple conditions testing the titlebar string to
know on which window to effect positioning and sizing actions, you
record a table of windows in WinSize2 to do the same. However, it looks
like this tool triggers when a object.window is created; i.e., when a
window opens is when WinSize2 exercises its rules.

If you have Nirsoft's nircmd.exe tool, you can use it to set the
coordinates and size of an opened window by running:

nircmd.exe win setsize title "<titlebar>" <x> <y> <width> <height>

<titlebar> is the string on which to test in the titlebars of the
currently opened windows. <x> and <y> are the coordinates for the upper
left corner of the window. <width> and <height> are obvious. Values
are in pixels. No, the angle brackets are not part of the arguments.
Alas, Nirsoft didn't bother to document the win setsize arguments at
http://www.nirsoft.net/utils/nircmd.html; however, the nircmd.chm help
file does mention the win arg and its setsize parameter.

You could have a "Restore Windows" folder with a bunch of shortcuts, or
a toolbar in the Windows Taskbar, or other means of storing a multitude
of nircmds for the windows you are likely to open and might need to
reposition and resize.

On Mon, 23 May 2022 11:27:18 +0100, "J. P. Gilliver (John)"
<G6JPG@255soft.uk> wrote:

>(I'm on 7, but the problem applies to XP and 10 too, and the solution -
>if there is one! - may be universal.)
>
>Occasionally, I accidentally either move a window, or drag one of its
>sides, by mistake - while doing (or intending to) something else with
>the mouse pointer, it catches on an edge, or more likely a title bar.
>(Unlike a lot of people, I _don't_ operate most of my windows
>full-screen most of the time,

Same for me. I almost never run anything full screen.

>so their relative sizes and positions are
>important to me.)
>
>I discovered fairly recently that _if I notice while the movement is in
>process_ (I just see the _outline_ move, i. e. I've still got the "mouse
>button pressed" [actually I use a touchpad, but similar applies]), I can
>cancel the move/resize by - keeping the button pressed and - pressing
>the Esc key. But if I don't - anyone know of a way of undoing a window
>move/resize? (Ctrl-Z doesn't seem to work.)

Can't you just drag it back where it was? Or is that not precise
enough for you? That's what I do.

On Mon, 23 May 2022 13:35:15 +0100, "J. P. Gilliver (John)"
<G6JPG@255soft.uk> wrote:

>On Mon, 23 May 2022 at 08:13:58, Mayayana <mayayana@invalid.nospam>
>wrote (my responses usually FOLLOW):
>[]
>> Seems very unlikely. Move and resize are not up to
>>Windows. Programs handle it. A program may remember
>
>Interesting point.
>
>>where it was last and resume that position if the window
>>has been minimized or the program closed. But that's
>>up to the program author to write the code for storing
>>coordinates and then retrieving the data.
>
>Now you mention it, they _do_ remember (their position and size) when
>minimised - or maximised for that matter. (At least, I can't think for
>the moment of one that doesn't [obviously some have a fixed size].)

For some strange reason, one of the programs I always run (Directory
Opus) doesn't remember where it was if I reboot.

It's not a big deal, but it's a minor annoyance.

Mayayana,

> Firefox, for example, seems to check open instances and display
> multiple windows in cascade fashion.

Try using 0x8000, 0x8000 for the windows/dialogs initial position.

Regards,
Rudy Wieser

Mayayana,

> I still don't know where I'd spec H8000.

After posting I realized by explanation-fu left something to be desired :-\

When I create a dialog in a resourcefile I have something like this :

- - - - - - - - - - - - - - - - - -
#define IDD_BASEWIN 1000

IDD_BASEWIN DIALOG DISCARDABLE 300, 0, 200, 36
begin
.....
end
- - - - - - - - - - - - - - - - - -

The only thing you need to do is to replace the, in this case, "300, 0" with
"0x8000, 0x8000"

To be honest, I have not tried to do that with CreateWindow (seldom use it
anymore), but as far as I understood it works the same way there.

> But I think I know what you mean. If I open one window and
> set it, then subsequent windows would automatically cascade?

Not quite. It works for any program, and they do not even need to be the
same. IOW, it works for any child of the desktop. You can take it as the
OS'es effort to keep all (newly) placed windows visible (not one hidden
behind another).

> So FF is setting the first window and then leaving it to
> Windows if there's already one showing?

Its not about FF. Its about dialogs/windows in general. As you said
yourself, its ultimatily the window which decides where it gets placed.

I'm not sure if its fully comparable, but a quick test just now opening a
number of "file explorer" dialogs shows that the first one got create at its
old place, but the subsequent ones started to form in a cascading wise from
the top-left of the screen.

The "first one at its old place and the subsequent ones cascading from the
top-left" *might* have something to do with

HKEY_CURRENT_USER\Software\Microsoft\Windows\ShellNoRoam\Bags

(I was looking for an answer to the OPs question).

> I just tried Notepad. It opens to its last position but then
> every subsequent instance opens at the same spot, on top of
> each other.

Same here. It probably uses (the equivalent of) DS_CENTER as one of its
styles.

Regards,
Rudy Wieser

"R.Wieser" <address@not.available> wrote

| When I create a dialog in a resourcefile I have something like this :
| | - - - - - - - - - - - - - - - - - -
| #define IDD_BASEWIN 1000
| | IDD_BASEWIN DIALOG DISCARDABLE 300, 0, 200, 36

I see. VC++? I've only dabbled in that and never with GUIs.
I use VB6, generally. That does all the grunt GUI work behind the
scenes. When I load the window, before making it visible, I
look up where it should be and position it.

I use CreateWindowEx, but only for self-subclassing
userControls.

I'm going to miss VB6. I'd become fairly expert over the years,
easily creating self-subclassing control windows for maximum
speed and flexibility. At the same time it's easy to code. And
the software runs on virtually any existing Windows box with
no support files needed. Real Win32 software, not bloated
"apps" pasted together with Python, QT, .Net, Java, RT, or
worse.
But I don't code much now. I just don't need things that I
don't have. And it won't be long, I'm sure, before non-corporate
non-spyware is considered to be "illegal sideloading" and Windows
sends out a SWAT team to take down my EXE.... Strange to look
back and realize the age of popular computing lasted a mere
30-odd years.

Ken Blake <Ken@invalid.news.com> wrote in
news:ctdn8hp1hh8sjar1mi28n2bj59peuk1j2o@4ax.com:

> On Mon, 23 May 2022 11:27:18 +0100, "J. P. Gilliver (John)"
> <G6JPG@255soft.uk> wrote:
>
>>(I'm on 7, but the problem applies to XP and 10 too, and
>>the solution - if there is one! - may be universal.)
>>
>>Occasionally, I accidentally either move a window, or drag
>>one of its sides, by mistake - while doing (or intending
>>to) something else with the mouse pointer, it catches on an
>>edge, or more likely a title bar. (Unlike a lot of people,
>>I _don't_ operate most of my windows full-screen most of
>>the time,
>
>
> Same for me. I almost never run anything full screen.

I don't think that many people run everything 'full screen' (more likely meaning
'maximized').

On Tue, 24 May 2022 09:33:43 -0500, DanS
<t.h.i.s.n.t.h.a.t@r.o.a.d.r.u.n.n.e.r.c.o.m> wrote:

>Ken Blake <Ken@invalid.news.com> wrote in
>news:ctdn8hp1hh8sjar1mi28n2bj59peuk1j2o@4ax.com:
>
>> On Mon, 23 May 2022 11:27:18 +0100, "J. P. Gilliver (John)"
>> <G6JPG@255soft.uk> wrote:
>>
>>>(I'm on 7, but the problem applies to XP and 10 too, and
>>>the solution - if there is one! - may be universal.)
>>>
>>>Occasionally, I accidentally either move a window, or drag
>>>one of its sides, by mistake - while doing (or intending
>>>to) something else with the mouse pointer, it catches on an
>>>edge, or more likely a title bar. (Unlike a lot of people,
>>>I _don't_ operate most of my windows full-screen most of
>>>the time,
>>
>>
>> Same for me. I almost never run anything full screen.
>
>I don't think that many people run everything 'full screen' (more likely meaning
>'maximized').

When I worked in a cube farm at a large corporation, as I walked around
the place I noticed that virtually everyone ran their stuff maximized,
with the only exception being one woman who spent much of her time
resizing windows and moving them around on her screen. Admittedly, that
was just over a decade ago, so things may have changed now that bigger
screens and/or higher resolutions are available.

I still run almost everything maximized, with just a few exceptions. I
don't like unnecessary vertical/horizontal scrolling.

Mayayana,

> | When I create a dialog in a resourcefile I have something like this :
> |
> | - - - - - - - - - - - - - - - - - -
> | #define IDD_BASEWIN 1000
> |
> | IDD_BASEWIN DIALOG DISCARDABLE 300, 0, 200, 36
>
> I see. VC++? I've only dabbled in that and never with GUIs.

Nope, hand-crafted and to be compiled into a .RES file using brc32.exe
(Borland Resource Compiler). I'm the guy writing Windows programs in
Assembly, remember.

> I use VB6, generally

I have used VB5 myself (for work), and as far as I can remember you could
specify the starting coordinates of the dialog if you wanted. If you want
to use the "auto placement" of Windows it would not hurt to take a look.

It could even mean you would not need to add extra code in the create event
of the window to move it to its desired-by-you position anymore.

> Real Win32 software, not bloated "apps" pasted together with
> Python, QT, .Net, Java, RT, or worse.

:-) As an assembly programmer any language above it feels needlesly
bloated. Including good-old C and it derivatives.

> But I don't code much now. I just don't need things that I
> don't have.

To me it was and has again become a hobby. Instead of figuring sudokos or
jigsaw puzzles I try to "puzzle" programs together.

> And it won't be long, I'm sure, before non-corporate
> non-spyware is considered to be "illegal sideloading" and
> Windows sends out a SWAT team to take down my EXE....

:-) Thats pretty-much why I don't yearn for any of those blasted
"smartphones". Any OS which I am not the lord-and-master over isn't welcome
in my house. Its also is the reason why I still have XP as my major OS.

> Strange to look back and realize the age of popular computing
> lasted a mere 30-odd years.

Same for hobby electronics. For a number of years I designed circuits,
turned them into layouts and etched PCBs for them, drilled the holes and
soldered the components in. Nowerdays the miniaturisation of the components
doesn't allow for that anymore. A gone era.

Regards,
Rudy Wieser

"R.Wieser" <address@not.available> wrote

| Nope, hand-crafted and to be compiled into a .RES file using brc32.exe
| (Borland Resource Compiler). I'm the guy writing Windows programs in
| Assembly, remember.
|

Interesting. I didn't know that. I decided to learn assemby
at one point, but didn't get far. I'm not really a math person.
I'm sort of a design-builder, an expert at straddling science
and art, but not a master of either. So I write code with a
practical sense. Once it works I like to optimize, but what I
like about VB is that I can just skip all the grunt work and
focus on the main functionality.

I dabbled a bit in C++ and could see the appeal. Compared
to VB it's like riding without a seat belt or a floor. But I just
wasn't ambitious enough to master it. And it's a damned ugly
language.

| > Strange to look back and realize the age of popular computing
| > lasted a mere 30-odd years.
| | Same for hobby electronics. For a number of years I designed circuits,
| turned them into layouts and etched PCBs for them, drilled the holes and
| soldered the components in. Nowerdays the miniaturisation of the
components
| doesn't allow for that anymore. A gone era.
|

Ah. An oldtimer. I was never around for the early days. I only
discovered computers with Win98, when it became a car to drive
and not just an engineering challenge for greasemonkeys. I think
that crippled my understanding, partly. I'm an auto-didact in
GUI programming. So understanding what really happens underneath
came later and was hard for me to grasp. It's still not second nature
for me, the way it is with fully trained C++ programmers.

"DanS" <t.h.i.s.n.t.h.a.t@r.o.a.d.r.u.n.n.e.r.c.o.m> wrote

| I don't think that many people run everything 'full screen' (more likely
meaning
| 'maximized').
|

I certainly don't. I have a 27" monitor. Fullscreen would
have me turning my head back and forth to read. And it
would negate the advantage of being able to switch around
by clicking title bars.

But so many people today use phones as a primary device.
One app at a time. And many use laptops with small screens,
even if they never move it. Very few people consider ergonomic
design. I imagine that someone on a 15" laptop, using almost
exclusively MS Word, would have no reason not to have a
maximized window. They've crippled their functionality back
to 1998, but they don't notice.

On Mon, 23 May 2022 at 09:36:19, Ken Blake <Ken@invalid.news.com> wrote
(my responses usually FOLLOW):
>On Mon, 23 May 2022 11:27:18 +0100, "J. P. Gilliver (John)"
><G6JPG@255soft.uk> wrote:
>
>>(I'm on 7, but the problem applies to XP and 10 too, and the solution -
>>if there is one! - may be universal.)
>>
>>Occasionally, I accidentally either move a window, or drag one of its
>>sides, by mistake - while doing (or intending to) something else with
>>the mouse pointer, it catches on an edge, or more likely a title bar.
>>(Unlike a lot of people, I _don't_ operate most of my windows
>>full-screen most of the time,
>
>
>Same for me. I almost never run anything full screen.
>
Nice to know there are others like me! A lot of both people in general,
and programmers (especially web page designers), are (or act*) very
surprised when you explain this, and treat you/us as if you're being
awkward. (* I think in the case of programmers/designers, they just
_act_ that way because it's more work for them catering to us.)
>
>>so their relative sizes and positions are
>>important to me.)
[]
>Can't you just drag it back where it was? Or is that not precise
>enough for you? That's what I do.

Oh, usually it would be; however, if the move/resize is accidental - i.
e I was trying to do something else with the mouse - I'm not necessarily
sure, even roughly, what the original position/size _was_. (-:
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

in the kingdom of the bland, the one idea is king. - Rory Bremner (on
politics), RT 2015/1/31-2/6

R.Wieser <address@not.available> wrote:
[...]

> :-) As an assembly programmer any language above it feels needlesly
> bloated. Including good-old C and it derivatives.

Assembly is needlessly bloated! Real Men Microcode!

And using assembly just means you're too dumb to remember the opcodes.

:-) (for the HI)

On Tue, 24 May 2022 at 17:31:11, Frank Slootweg <this@ddress.is.invalid>
wrote (my responses usually FOLLOW):
>R.Wieser <address@not.available> wrote:
>[...]
>
>> :-) As an assembly programmer any language above it feels needlesly
>> bloated. Including good-old C and it derivatives.
>
> Assembly is needlessly bloated! Real Men Microcode!

Entering it with switches, of course. And hoping an insect - or to use
the US term, bug - doesn't end up in the relays, sorry, software ...
>
> And using assembly just means you're too dumb to remember the opcodes.

(-: (I can still remember the opcodes for the first computer I learnt on
- all 8 of them. Z [000], A, S, T, I, J, K, and E [111].) And yes, you
really _did_ program BRENDA with switches, though I don't think it had
relays, in the logic anyway.
>
>:-) (for the HI)
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

What's really worth knowing is for the most part unlearnable until you have
enough experience to even recognise it as knowledge, let alone as useful
knowledge. - Wolf K <wolfmac@sympatico.ca>, in alt.windows7.general, 2017-4-30

Mayayana,

> I'm not really a math person.

Neither am I. Luckily it hasn't stopped me.

> but what I like about VB is that I can just skip all the
> grunt work and focus on the main functionality.

And there I am, thinking that all those (system) DLLs are doing the grunt
work for me. I only have to stich a few functions outof them together and
magic happens. :-)

> I dabbled a bit in C++ and could see the appeal. Compared
> to VB it's like riding without a seat belt or a floor.

I can only imagine that doing Assembly must have been awfull for you, not
even knowing which side was up ...

Using higher programming languages I was always troubled by the distance
between what I wrote and what it actually got compiled into. It didn't
help to read that the compiler could sometimes just "optimize" whole swats
of code away, making it not do what the programmer intended.

And the almost always needed typecasting, because everyone can define their
own type names. Very funny when you have to deal with a couple of
DLLs/externam modules that have been written by different people ...

> Ah. An oldtimer.

You could say that I guess.

> I was never around for the early days. I only discovered computers
> with Win98,

My own first contact with computers was a 8080 processor based (later
upgraded to a Z80 processor) non-name home-build by the leader of the
electronics club I had become a member of (learned my transistors there).
After a number of years and a series of other 8-bitters (TRS80, Apple 2e,
C64 to name a few) my first own PC was a 286 running DOS 3.3 with a *BIG*
harddisk. A whopping 40 Megabyte of it. :-)

> when it became a car to drive and not just an engineering
> challenge for greasemonkeys.

I'm not much of an engineer, but I'm afraid that I am one of those
"greasemonkeys". I have /way/ to much fun in having the 'puter do what /I/
want instead of the other way around.

> I'm an auto-didact in GUI programming.

Although I had some helpfull people around in my early days on that
8080-based 'puter most of the later stuff learned with the help of library
books and later the internet. So, also auto-didact. Certainly whole
Windows part.

> So understanding what really happens underneath came later and was
> hard for me to grasp. It's still not second nature for me, the way
> it is with fully trained C++ programmers.

I've disassembled enough programs make me wonder how many of those "fully
trained C++ programmers" who know what is going on beneath their feet ...

Than again, part of the ugly and rather clumsy code I sometimes see could be
the result of a bad compiler. Who knows.

Regards,
Rudy Wieser

Frank,

> Assembly is needlessly bloated! Real Men Microcode!

And when they need to change it they do it on the chip, using a fine-pointed
needle to flip the bits !

> And using assembly just means you're too dumb to remember the opcodes.

Ackkk... You got me there I'm afraid. Never been able to remember just a
meager few of them .. :-p

Regards,
Rudy Wieser

In article <t6j82u$uno$1@gioia.aioe.org>, R.Wieser
<address@not.available> wrote:

> Using higher programming languages I was always troubled by the distance
> between what I wrote and what it actually got compiled into. It didn't
> help to read that the compiler could sometimes just "optimize" whole swats
> of code away, making it not do what the programmer intended.

optimizing means make it faster. it does *not* mean change what it does.

> And the almost always needed typecasting, because everyone can define their
> own type names. Very funny when you have to deal with a couple of
> DLLs/externam modules that have been written by different people ...

typecasting is a very good thing. it's much easier to find errors at
compile time rather than at run time, surprising the user, which is
never a good thing.

> > when it became a car to drive and not just an engineering
> > challenge for greasemonkeys.
>
> I'm not much of an engineer, but I'm afraid that I am one of those
> "greasemonkeys". I have /way/ to much fun in having the 'puter do what /I/
> want instead of the other way around.

who intentionally writes code that does something they don't want?

> > So understanding what really happens underneath came later and was
> > hard for me to grasp. It's still not second nature for me, the way
> > it is with fully trained C++ programmers.
>
> I've disassembled enough programs make me wonder how many of those "fully
> trained C++ programmers" who know what is going on beneath their feet ...

they know far more about what's going on than assembly programmers, who
can't see the big picture.

put another way, they deal in concepts, not micromanaging bits.

> Than again, part of the ugly and rather clumsy code I sometimes see could be
> the result of a bad compiler. Who knows.

not you.

"Mayayana" <mayayana@invalid.nospam> wrote in
news:t6j08a$c6h$1@dont-email.me:

> "DanS" <t.h.i.s.n.t.h.a.t@r.o.a.d.r.u.n.n.e.r.c.o.m> wrote
>
>| I don't think that many people run everything 'full
>| screen' (more likely
> meaning
>| 'maximized').
>|
>
> I certainly don't. I have a 27" monitor. Fullscreen would
> have me turning my head back and forth to read. And it
> would negate the advantage of being able to switch around
> by clicking title bars.
>
> But so many people today use phones as a primary device.
> One app at a time. And many use laptops with small screens,
> even if they never move it. Very few people consider
> ergonomic design. I imagine that someone on a 15" laptop,
> using almost exclusively MS Word, would have no reason not
> to have a maximized window. They've crippled their
> functionality back to 1998, but they don't notice.

You know, after I posted my comment, I started to think about it a little more about it...

The first thing that came to mind when I read the OP, was Facebook. If you run
Facebook maximized, on say a 27" monitor, there are HUGE, huge areas of wasted
white space on both sides of the screen.

But the more I thought about it, I do realize I do run a lot of stuff maximized, but only
programs where being maximized improves the s/w use.

I do CAD work, always maximized. The more you see, the better. Spreadsheets too,
sometimes, as the boss is really hip on "just add another column!" after there's already
50 columns in his spreadsheets. Using VS is often maximized. I can pull several code
windows of tabs into separate windows to reference back and forth between them.

Audio and video editing is always maximized...the more you can see at once, the
better.

I'm writing this post right now, from work, as I'm on break and RDP'd into my home
machine, in fullscreen.

On a side/related note...

When Windows 11 came out, and listed one of the new 'features' is that you set the
start button to be in the middle of the tasbar, instead of all the way to the left bottom
corner. I balked at that, likw wow!!!! that's a feature, you need to tout?!?!...

Fast-forward in time, and I'm in front of my studio PC with Pro Tools maximized, the
the 34" ultra-wide I'm using for that, and need to get tot he Start Menu...

....it was at that point, I realized that perhaps that is a cool feature, because I found I had
to move my head diagonally quite a bit to focus almost two feet away from what I was
looking at to 'get to' the Start button way the hell down over there!

I used to be like you, Mayayana...I hated anything new that came out, especially
Windows, as each version would get more bloated with all this junk I'll never need or
use, and be super-cncerned about *everything*...I mean, I even wrote my own
Windows shell to replace Explorer as a shell, so it would work l;ike I wanted it to, and
be efficient like I thought it should be.

....at some point, you start going through so much work to not do/have anything new,
updated, or upgraded, that it just not worth a the hassle. What is gained, is not more
than the effort but forth to do so. (For me anyway.)

I mean, if you've got an older PC being used, that's fine, but to like buy new hardware in
202x and want to use XP on it??

Don't get me wrong...I do do some trimming, and customization, just not anywhere
near to the degree I used to.

nospam,

> optimizing means make it faster.

No, it doesn't. Not by a long shot. Though mostly the /effect/ of those
optimalisations is a faster running program.

> it does *not* mean change what it does.

Do a wild guess why I put the word between quotes ...

> typecasting is a very good thing.

In its intention ? Sure. But not when the programmer gets warnings about
them every second variable he's trying to use. Which /will/ happen when
trying to use third-party stuff - for the reason I already described.

>> I'm not much of an engineer, but I'm afraid that I am one of those
>> "greasemonkeys". I have /way/ to much fun in having the 'puter do what
>> /I/
>> want instead of the other way around.
>
> who intentionally writes code that does something they don't want?

Lol. I suggest you re-read what I said. Focus on the last line you quoted.

If that doesn't help, think about you and a car salesman. What would you
like better : the car salesman taking you for a ride, or the other way
around.

> they know far more about what's going on than assembly programmers,
> who can't see the big picture.

If you say so.

> put another way, they deal in concepts, not micromanaging bits.

Yep. And by that feat they lose sight of the cost of what they write - and
depend on their compilers to optimize whatever they come up with into the
most optimum form possible.

> not you.

Yep, that is what I said. You're not a real brainiac, are you ?

Regards,
Rudy Wieser