On Tue, 6 Jun 2023 20:04:23 +0200, "R.Wieser" <address@is.invalid>
wrote:

>Ken,
>
>> "Old" is certainly not the same as "bad."
>
>I know that, you know that. But some people only want/need/demand to have
>the latest-and-advertised-greatest bling-bling, and will regard everything
>else - even if its what they used yesterday - as inferior. yup, a status
>thing.

Very true.

>> The older it gets the more likely it is that you're going to want
>> or need some new hardware or software that isn't compatible with it.
>
>True. And when that happens its early enough to switch to something else.

Yes, but...

....if you let several versions go by and then switch to the latest
version, it will probably be a big change and difficult to learn how
to use the new one. Changes are easier to adapt to when they are
gradual.

>> If you haven't yet run into such a problem, fine. But one of
>> these days...
>
>I already have gone to one such change six years ago, when my W98 'puters
>motherboard died and W98 drivers for a new motherboard (and associated
>hardware) was ofcourse nowhere to be had. Result : I'm now running XP.
>
>Yes, you read that right. Up until about late 2017 I ran W98.
>
>Regards,
>Rudy Wieser
>

Ken,

> ...if you let several versions go by and then switch to the latest
> version, it will probably be a big change and difficult to learn
> how to use the new one. Changes are easier to adapt to when they
> are gradual.

How is changing from W98 to XP to W7 to vista to W8 to W10 to W11 anything
near to gradual ?

But if you are talking about the continuous stream of updates to the
user-facing part of the OS (which causes it to be in a permanent state of
flux), than no thank you. Yuck and all that.

And thats besides the problem that MS took away the users choice in it (even
going as far as ramming W10 and now W11 down they users collective throaths)
and that it continously mucks around with the users preferences. I would
*definitily* not like that.

Also, I would not like it one bit of such a "gradual change" would suddenly
cause some other programs I installed to stop working.

No, I think I prefer a stable, dependable system that I replace once every
two decades over one which continuously demands my attention because
/something/ changed. :-)

But thanks for reminding me, I should really put a 'puter with Win7 on it
next to me, so I can get aquainted with it at my leisure. Something I'm
already doing with Linux (Raspberry Pi) ...

Regards,
Rudy Wieser

R.Wieser <address@is.invalid> wrote:
[...]

> Well, as an Assembly programmer I can't really deny that, can I ? :-)

Assembly is for wimps! Real Programmers (TM) cat to a.out!

Frank Slootweg wrote:
> R.Wieser <address@is.invalid> wrote:
> [...]
>
>> Well, as an Assembly programmer I can't really deny that, can I ? :-)
>
> Assembly is for wimps! Real Programmers (TM) cat to a.out!

Have you ever used Assembler on an old first generation mainframe? A
piece of hardware with thermionic valves?
Or on a ZX Spectrum to alter some game?
Well, I have. And it's hardly for wimps! It takes a degree of skill that
today's high-level languages can't even dream of.
Just try and wriggle some disassembler between the screen parameters and
the game prog on a Spectrum, and then rale at assembler programmers.
Or peruse an old ICL mainframe core dump in binary, octal and
hexadecimal; trying to find the error.

Your "real programmers" are the wimps. They don't work within the
constraints that we worked within in the "white-hot heat of the
technological revolution". They're pampered children of the revolution.

Ed

Frank,

> Assembly is for wimps! Real Programmers (TM) cat to a.out!

Obligatory XKCD reference : https://xkcd.com/378/

Regards,
Rudy Wieser

Ed,

>> Assembly is for wimps! Real Programmers (TM) cat to a.out!
>
> Have you ever used Assembler on an old first generation mainframe? A piece
> of hardware with thermionic valves?

He wasn't trying to tell me that high-level programs are better, he was,
jokingly, one-upping me and suggesting that I have it /way/ too easy.

Have you ever tried to enter 4K of code on a ZX Spectrum, hoping you did
everything right the first time (or you could start all over again) ? Thats
the problem you will encounter using "cat to a.out!" (or its DOS equivalent,
COPY CON). As such writing Assembly using an editor and converting it to
an executable using an assembler is a breeze. :-)

Regards,
Rudy Wieser

Ed Cryer <ed@somewhere.in.the.uk> wrote:
> Frank Slootweg wrote:
> > R.Wieser <address@is.invalid> wrote:
> > [...]
> >
> >> Well, as an Assembly programmer I can't really deny that, can I ? :-)
> >
> > Assembly is for wimps! Real Programmers (TM) cat to a.out!
>
> Have you ever used Assembler on an old first generation mainframe? A
> piece of hardware with thermionic valves?

I've worked on the first 16-bit 'mini' computers with 4-32K (words).
I've modified the 64-word BBL (Basic Binary Loader), so that it could
not only handle boot from papertape and disc (c, not k), but could also
do dual-boot (BCS and DOS-M) from disc.

I've modified and written device drivers and written very, very
low-level memory-mapping routines in Assembler.

> Or on a ZX Spectrum to alter some game?

I've disassembled MSX games (Z-80) and modified them to allow them to
be stored on and loaded from diskette, instead of from (audio) cassette
tape.

> Well, I have. And it's hardly for wimps! It takes a degree of skill that
> today's high-level languages can't even dream of.
> Just try and wriggle some disassembler between the screen parameters and
> the game prog on a Spectrum, and then rale at assembler programmers.
> Or peruse an old ICL mainframe core dump in binary, octal and
> hexadecimal; trying to find the error.

So yes, I *do* know what it takes. That was the whole point of the
joke.

> Your "real programmers" are the wimps. They don't work within the
> constraints that we worked within in the "white-hot heat of the
> technological revolution". They're pampered children of the revolution.

I take it you didn't get the "cat to a.out" bit. 'My' programmers
directly type the opcodes into the executable file [1]. We had a guy who
could read ASCII paper tapes with his eyes.

But I do understand *your* point, I already encountered your kind of
programmers in the 70s. One of them was lucky we were on a plane,
otherwise I would have kicked him out! :-)

[1] Yes that can be done: The (comp.binaries.ibm.pc) 'CBIP Starter's Kit'
was distributed as a Usenet posting, where part of the text of the
posting could be cut out, saved in a file, renamed as a .com and
executed to uudecode the rest of the posting. (I still have a copy of
such a posting.)

R.Wieser <address@is.invalid> wrote:
[...]
> Have you ever tried to enter 4K of code on a ZX Spectrum, hoping you did
> everything right the first time (or you could start all over again) ? Thats
> the problem you will encounter using "cat to a.out!" (or its DOS equivalent,
> COPY CON). As such writing Assembly using an editor and converting it to
> an executable using an assembler is a breeze. :-)

Thanks. The 'COPY CON' one refused to be loaded into my foreground
memory, so I used the Unix equivalent. Yes, a BIG faux pas in a Windows
group!

R.Wieser <address@is.invalid> wrote:
> Frank,
>
> > Assembly is for wimps! Real Programmers (TM) cat to a.out!
>
> Obligatory XKCD reference : https://xkcd.com/378/

Nice one! I had never seen the butterfiles one.

In message <u5qum9.dpg.1@ID-201911.user.individual.net> at Wed, 7 Jun
2023 20:00:51, Frank Slootweg <this@ddress.is.invalid> writes
>R.Wieser <address@is.invalid> wrote:
>[...]
>> Have you ever tried to enter 4K of code on a ZX Spectrum, hoping you did
>> everything right the first time (or you could start all over again) ? Thats
>> the problem you will encounter using "cat to a.out!" (or its DOS equivalent,
>> COPY CON). As such writing Assembly using an editor and converting it to
>> an executable using an assembler is a breeze. :-)
>
> Thanks. The 'COPY CON' one refused to be loaded into my foreground
>memory, so I used the Unix equivalent. Yes, a BIG faux pas in a Windows
>group!

I _have_ occasionally used COPY CON: to create a small batch file. Yes,
nothing like what you are thinking of, but an actual practical example.

(The first computer - by Mr. Parr's definition, which was that its
instruction set included a conditional jump - that I used, you _did_
program one bit at a time. [A 7-bit serial-processor machine that ran in
_ones_ complement; called BRENDA.])
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

"Address the chair!" "There isn't a chair, there's only a rock!" "Well, call
it a chair!" "Why not call it a rock?" (First series, fit the sixth.)

Frank,

> Nice one! I had never seen the butterfiles one.

No doubt drawn from the chaos principle (a butterfly flapping its wings in
America could cause a storm in Europe).

I like the "magnetised needle" best myself, its almost believable.

Regards,
Rudy Wieser

Newyana2,

As you have mentioned to have done quite a bit with the RichEdit control,
maybe you can help me understand a problem I had a while ago.

I loaded an RTF file (containing multiple font sizes) into a RichEd20
control, Than Itried to save the cursor position using EM_GETSCROLLPOS and
later restore the position using EM_SETSCROLLPOS.

The problem ? Even when I executed those two commands directly after the
other* the cursor jumped up a number of lines.

*automatically executed or delayed by putting it under a button I had to
press first made no difference.

If you ever ran into it and fixed it, how did you do that ?

Regards,
Rudy Wieser

P.s.
I posted the question here as you frequent this newsgroup. But I've set
the follow-up to "comp.os.ms-windows.programmer.win32". If thats not a
newsgroup your newsgroup provider carries than please remove the
redirection.

"R.Wieser" <address@is.invalid> wrote

| As you have mentioned to have done quite a bit with the RichEdit control,
| maybe you can help me understand a problem I had a while ago.
| | I loaded an RTF file (containing multiple font sizes) into a RichEd20
| control, Than Itried to save the cursor position using EM_GETSCROLLPOS and
| later restore the position using EM_SETSCROLLPOS.
| | The problem ? Even when I executed those two commands directly after the
| other* the cursor jumped up a number of lines.
|

I sandwich operations between LockWindowUpdate
on the parent window. I also sometimes add EnableWindow
on the RichEdit itself. The former blocks painting. The
latter blocks input from mouse and keyboard.

DoEvents
LockWindowUpdate ParentWindow.hWnd
EnableWindow hRE.hWnd, False

' [Here I might do something like read out the
RE content and run the string through a tokenizing
routine to update formatting, colors, or whatever,
then put back the new RTF text.]

EnableWindow hRE.hWnd, True
LockWindowUpdate 0

At some point MS decided LockWindowUpdate should not be
used and recommended a WM_SETREDRAW message instead.
If I remember correctly, LWU wraps that message along with
other operations. I never understood the hubbub. Raymond
Chen goes on about how all hell will break loose if you start
running LWU on multiple windows because there's no window
handle for unlocking. But I don't see a problem with that. I'm
not doing it with multiple windows and I only do it for a fraction
of a second. It may be possible for another program to make
the same call during that fraction of a second while someone is
using my editor, but that's farfetched. At any rate, you can try
WM_SETREDRAW. Both block painting but keep track of changes
for painting after unlock. EnableWindow, by contrast, is used to
block input to the window entirely while a locking operation is
going on.

I find that if I can do all operations in less than 1/4 second
then the window display is smooth and the content just updates
in appearance. I don't if that covers the problem you're having.
I Guess I typically record SelStart before any operation and
then return it to that position. EM_GETSEL and EM_SETSEL.

I don't get how you're doing any of this with script, but I'll
leave you to it. :) However, getting, setting SelStart requires
a long pointer to a CHARRANGE STRUCT. The STRUCT is two
longs, which specify the starting point and ending point of
a specified set of characters. You dson't have to care about that
if you just return the CHARRANGE from GET to the SET operation,
but you will need to handle a CHARRANGE.

| P.s.
| I posted the question here as you frequent this newsgroup. But I've set
| the follow-up to "comp.os.ms-windows.programmer.win32". If thats not a
| newsgroup your newsgroup provider carries than please remove the
| redirection.
|

I'll find out, I guess. I'm setting it for both, since
it's possible someone here would be curious. I used
to visit maybe 6-7 programming groups, including
Win32 API. I didn't know there were any still left.
The only one I still go to is vb.general.discussion,
which still gets regular traffic.

[f/u removed, as I don't read the other group]

On Tue, 13 Jun 2023 10:08:57 +0200, "R.Wieser" <address@is.invalid>
wrote:

>Newyana2,
>
>As you have mentioned to have done quite a bit with the RichEdit control,
>maybe you can help me understand a problem I had a while ago.
>
>I loaded an RTF file (containing multiple font sizes) into a RichEd20
>control, Than Itried to save the cursor position using EM_GETSCROLLPOS and
>later restore the position using EM_SETSCROLLPOS.
>
>The problem ? Even when I executed those two commands directly after the
>other* the cursor jumped up a number of lines.
<snip>

After you call EM_GETSCROLLPOS, can you print its value to the console
for inspection? Perhaps it needs to have a static offset applied before
you use it in EM_SETSCROLLPOS, although I don't know why.

Char,

> After you call EM_GETSCROLLPOS, can you print its value to the
> console for inspection?

I have. And I did it again after having applied EM_SETSCROLLPOS. The
results differed.

> Perhaps it needs to have a static offset applied before
> you use it in EM_SETSCROLLPOS, although I don't know why.

The MSDN webpages to either EM_GETSCROLLPOS or EM_SETSCROLLPOS do not make
any mentioning of it :

https://learn.microsoft.com/en-us/windows/win32/controls/em-getscrollpos

https://learn.microsoft.com/en-us/windows/win32/controls/em-setscrollpos

And by the way: the reason why I mentioned "(containing multiple font
sizes)" is that if you load an RTF file that does /not/ set the font size
(leaves it default) everything works. IOW, no offset.

Regards,
Rudy Wieser

Newyana2,

> I sandwich operations between LockWindowUpdate on the parent
> window. I also sometimes add EnableWindow on the RichEdit itself.

I just tried either and both LockWindowUpdate and EnableWindow but alas, I
got the same jumping result.

Thanks for the suggestion though.

> I'll find out, I guess. I'm setting it for both, since
> it's possible someone here would be curious.

That indeed has happened. I was hoping they would move to this
(comp.os.ms-windows.programmer.win32) newsgroup too.

> I used to visit maybe 6-7 programming groups

Most of the programming newsgroups I visit are of little usage to me, as my
questions are seldom about the language, but instead about the underlaying
controls, DLL functions, etc.

Regards,
Rudy Wieser

"Char Jackson" <none@none.invalid> wrote

| After you call EM_GETSCROLLPOS, can you print its value to the console
| for inspection? Perhaps it needs to have a static offset applied before
| you use it in EM_SETSCROLLPOS, although I don't know why.
|

No. I use it to line up RichEdits or to reset a window
to where it was after doing operations. I just save the
POINT values from GET and then reuse them in SET.

It would be rare to
do anything else because you wouldn't know how to
measure. For example, you might call GET and return
40, 300. Then maybe you want to scroll down 200 pixels?
But why? That's never relevant. A RichEdit provides
EM_LINESCROLL for scrolling a number of lines, which
actually is useful.

"R.Wieser" <address@is.invalid> wrote

| I just tried either and both LockWindowUpdate and EnableWindow but alas, I
| got the same jumping result.
|

I don't see how that's possible. If you do a LWU, then
save the cursor pos, then do operations, then reset
the cursor, then unlock window, it's not possible for
the window to move while you're doing all that.

Did you also save and reset the SelStart position?
If you do as above but end up with SelStart (cursor pos)
several lines away, then it will jump. You have to put
everything back as it was before you unlock.

Newyana2,

> I don't see how that's possible.

I don't either, but it still does.

I just retried it, and it behaves the same. To double-check I removed the
unlocking, and afterwards, as expected, wasn't able to interact with the
RichEdit control anymore.

And something I did not mention before : the jumps seem to get smaller the
closer the cursor gets to the top.

> Did you also save and reset the SelStart position?

No. Why should I ?

Ehhrrmmm... I said I saved the /cursor/ position, but as you probably have
noticed fromk the used EM_xxx messages, I was trying to save and restore the
position of the "view". IOW, I'm not even touching the cursor (anymore).

For reference, here is the code thats under the button :

;-- Get the current scrollpos location
call SendMessageA,[@@hWnd],EM_GETSCROLLPOS, 0, ebx

;-- go to that same location
call SendMessageA,[@@hWnd],EM_SETSCROLLPOS, 0, ebx

(some debugging-output snipped)

> If you do as above but end up with SelStart (cursor pos)
> several lines away, then it will jump.

I start with the cursor in the view. When I than click the button the view
jumps /away/ from it, in the direction of the start of the file.

Looking at the vertical scrollbar it jumps to a position halfway between the
current position an the top of the text. Scrolling the view using that
scrollbar works normally.

I have absolutily no idea what is happening. :-(

Regards,
Rudy Wieser

"R.Wieser" <address@is.invalid> wrote
| | > Did you also save and reset the SelStart position?
| | No. Why should I ?
| |
| Ehhrrmmm... I said I saved the /cursor/ position, but as you probably
have
| noticed fromk the used EM_xxx messages, I was trying to save and restore
the
| position of the "view". IOW, I'm not even touching the cursor (anymore).
| | For reference, here is the code thats under the button :
| | ;-- Get the current scrollpos location
| call SendMessageA,[@@hWnd],EM_GETSCROLLPOS, 0, ebx
| | ;-- go to that same location
| call SendMessageA,[@@hWnd],EM_SETSCROLLPOS, 0, ebx
| | (some debugging-output snipped)
| | > If you do as above but end up with SelStart (cursor pos)
| > several lines away, then it will jump.

The button? You click a button to run the test?
I don't know whether that might affect it, since it takes
focus from that window. But I'm not really understanding
what you're doing, or why you need a button.

GETSCROLLPOS is not the same as cursor position.
Cursor position is EM_EXGETSEL and EM_EX_SETSEL.
It's a CHARRANGE that describes the selection offset in
characters and the selection length. So, for example,
if you send EX_SETSEL with 100, 100 then you'll put the
cursor at the 100th character with no selection length.

SCROLLPOS is the scrolled position of the RichEdit window
in relation to the upper left corner.

How about if you just do the operation you want without
the button? In other words, do what you actually want to
do with the text. Say, for example, that you're going to
change the font of some words and the color of others. Then
you get your cursor point and scrollpoint, you lock the window,
you do your changes, you reset scroll and cursor, and finally
you unlock. Not via a button by via code. If you have to
use the button then you might need to always track cursor
and scroll positions, so that you know where they were when
the RE loses focus.

If you change the actual text then of course you'll need to
account for that. For example, if the cursor is at char 542 and
you remove the first 100 characters, then 542 will be a
different position in the text and a different line will be the line
where you were before.

Newyana2,

> The button? You click a button to run the test?

Yes. Exactly because its a test.

> I don't know whether that might affect it, since
> it takes focus from that window.

I moved it from the WM_INITDIALOG code to in a WM_COMMAND bit of code (for
the buttons event) - as a control might not be fully initialized in
WM_INITDIALOG, skewing the result.

> But I'm not really understanding what you're doing,

Currently ? Trying to figure out what causes that jump.

Later on ? Use it to save the current "view" position when I close the
program, so that it can be restored next time I open it.

> or why you need a button.

I needed a way to get those two lines of code executed somehow and I wanted
to remove as much as non-essential code as possible (the actual saving on
close and loading on opening the program) so it could not interfere (read:
cause the problem).

> GETSCROLLPOS is not the same as cursor position.
> Cursor position is EM_EXGETSEL and EM_EX_SETSEL.

Yes, that was my mistake in naming the problem. Its about saving/restoring
the views position, not the cursor.

> SCROLLPOS is the scrolled position of the RichEdit window
> in relation to the upper left corner.

I would have thought so too (reading the MSDN documentation), but here I am,
with two lines of code which do not do what thay are supposed to do. :-(

> How about if you just do the operation you want without
> the button? In other words, do what you actually want to
> do with the text.

That is what I started with and where I noticed the problem. From that I
went into "bug hunting mode", stripping as much irrelevant-to-the-problem
code as I could while keeping the problem itself. Its how I ended up with
the two lines I posted.

> If you change the actual text then of course you'll need to
> account for that.

:-) I'm aware of that, thank you.

Again, my code is now retrieving the views current location and than telling
it to move *to that same position*. IOW, the view should not move at all.
Yet, it does. :-(

Extra info:
I mentioned that the view jumps to a position roughly halfway the distance
between its current position and the top of the text. Subsequent presses
of the button repeated that effect, roughly halving the distance every time.
IOW, its not an offset problem.

I also turned the whole thing upside-down by setting the views location to a
specified one, and than ask where it thought it was.

set get
----- ----
500 -> 159
12000 -> 3811
21000 -> 6669

The funny thing is that when I divide the latter by the former the factor is
the same every time : 0.31757.

Holdup, let me try something ....

I just "compiled" the program again, but removed the (dialog definition)
line specifying the dialogs default font and size. The "get" result
changed. Why ? Beats me.

I than also told the RichEdit control to load plain text (instead of RTF
text, which uses several font sizes). The "get" result again changed.

IOW, *something* is messing with the "get" result, and it ain't me. <phew!>

To be absolutily clear about it, the RichEdit control gets created and
filled with text /way/ before I press the "test" button. And the code
behind that button only contains (besides some debugging output) the
EM_GETSCROLLPOS and EM_SETSCROLLPOS commands. No "funny stuff" of any
kind.

Regards,
Rudy Wieser

Newyana2,

> ... I wanted to remove as much as non-essential code as possible (the
> actual saving on close and loading on opening the program) so it could
> not interfere (read: cause the problem).

Just now I realized that I applied some extra settings to the RichEdit
control, and disabled all of it. As a result the "set" and "get" started to
match. Victory ! (even though not all of the RTF file gets loaded)

.... well, not quite : what's causing it ?

It turns out that when use EM_EXLIMITTEXT (so I can load more than 64K of
RTF) it starts to happen. When I set it to something like 0x50000 the "set"
and "get" values start to get different, with the difference becoming larger
the higer that the EM_EXLIMITTEXT value is.

Do I have any idea why that its happening ? Nope. Is it in any way
mentioned on the MSDN webpage explaining EM_EXLIMITTEXT ? Also nope.

Regards,
Rudy Wieser

"R.Wieser" <address@is.invalid> wrote

| It turns out that when use EM_EXLIMITTEXT (so I can load more than 64K of
| RTF) it starts to happen. When I set it to something like 0x50000 the
"set"
| and "get" values start to get different, with the difference becoming
larger
| the higer that the EM_EXLIMITTEXT value is.
| | Do I have any idea why that its happening ? Nope. Is it in any way
| mentioned on the MSDN webpage explaining EM_EXLIMITTEXT ? Also nope.
|

I use 8000000 (decimal). I don't remember how I came up
with that number. But I doubt it's doing anything but changing
the theoretical height of the window. Something else seems
to be affecting the jumping. As my father used to say when no
one would admit to breaking something, "I guess a ghost must
have done it." :)

If it were me I'd lock the window, load the file, set the
cursor position, then unlock. The cursor is automatically
scrolled into view, so you don't need the scroll position.
And scroll position could change, as you say, with font
changes. But cursor position won't change because it's
a character offset rather than a window display setting.

If you want to keep doing it as you're doing it then maybe
start eliminating factors more. For instance, you could load
the file from within code. I'm not clear about the dialogue.
You're making your own window? If you're calling GetOpenFileName
then the dialogue window is gone when you get the file path,
so it shouldn't be a factor. But if you're making your own window
or sub-frame I suppose it could affect where the focus goes.

Newyana2,

> But I doubt it's doing anything but changing
> the theoretical height of the window

I used different numbers to EM_EXLIMITTEXT, set a constant position using
EM_SETSCROLLPOS and saw the EM_GETSCROLLPOS return different values. If its
not /the/ cause than it still influences it - even though, as you remarked,
it should not have to do anything with it.

> If it were me I'd lock the window, load the file, set the
> cursor position, then unlock.

Its currently not about restoring the views position (I used another approch
which seems to work alright, even if a bit clumsy), but about determining if
I should remove the EM_GET- and EM_SETSCROLLPOS from the list of usable
messages - so I won't run into something similar in the future.

By the way: I found, while googeling, a few other messages about having the
same problem. None of them mentioned a solution to it.

> If you want to keep doing it as you're doing it then maybe
> start eliminating factors more.

Such as ?

> For instance, you could load the file from within code.

I'm already doing that. Starting a program after each small edit (trying to
locate the problem) and than having to load the same file over-and-over
again quickly becomes tiresome.

Besides, bughunting should not be done on something you're (unknowingly,
mistakingly) changing the parameters to. IOW, for/during my testing the
filename (and (thus) the loaded text) is a constant.

> I'm not clear about the dialogue. You're making your own window?

You always do. :-) In my case I describe a dialog in a resource file, and
than load that resource using "call DialogBoxParamA,0, IDC_DIALOG,0,offset
DialogCB,0"

Also, as mentioned, the reason why I found EM_EXLIMITTEXT to be involved is
because I effectivily disabled /everytyhing/. And that was enough to make
the problem disappear - on the cost of only seeing a partially-loaded RTF
file.

If you want to see the full sourcecode (or certain parts thereof) you only
have to ask. I have no problem with posting it (here and/or to an email
addres).

Remark: Its in Assembly (should not be too hard to read, but you never
know).

Regards,
Rudy Wieser

"R.Wieser" <address@is.invalid> wrote

| > I'm not clear about the dialogue. You're making your own window?

| You always do. :-) In my case I describe a dialog in a resource file, and
| than load that resource using "call DialogBoxParamA,0, IDC_DIALOG,0,offset
| DialogCB,0"

I've never used that. I use GetOpenFileName, to
give me a system file-open window with all the fixings.

|
| If you want to see the full sourcecode (or certain parts thereof) you only
| have to ask. I have no problem with posting it (here and/or to an email
| addres).
| That might be good. I'm having trouble following. I thought
you said the problem was with loading a file, and now you say
it isn't. So I don't really understand what you're doing. If I
can make out the code then I might be able to run my own test.