tlandry | 4 Sep 2001 12:39

When to call CScrollWindow::SetScrollSize()

In my CScrollWindowImpl derived class I call SetScrollSize() in 
OnCreate(). When the window opens, the scrollbars are not set 
properly.

Currently I am calling SetScrollSize in WM_SIZE event, after the base 
class gets a crack at it. This works, but it is not the best place to 
put it because everytime I resize the Window, the scrollbars get 
reset.

In what event is it recommended to call SetScrollSize() if I know the 
sizes at compile time?

BTW: CScrollWindowImpl is very cool. Much more flexible and simple 
than the MFC CScrollView.

Any suggestions? 

Thanks,

Ted

BRANDON C CORFMAN | 4 Sep 2001 14:49
Picon

Re: When to call CScrollWindow::SetScrollSize()

Ted,

What you're doing sounds fine to me. For the CPrintPreviewWindowEx class in my PhoneList program, I called
SetScrollSize in two places: in an
initialization function for my window (akin to OnInitDialog) and also in OnSize. But I also called
CScrollWindowImpl::SetScrollOffset and
::ScrollWindowEx to reposition the window to the correct offset. I used ::GetScrollInfo to obtain the
previous scrollbar offset, but I've
discovered since that CScrollWindowImpl has the simpler GetScrollOffset, which you can use as an alternative.

Best regards,
Brandon

tlandry@... wrote:

> In my CScrollWindowImpl derived class I call SetScrollSize() in
> OnCreate(). When the window opens, the scrollbars are not set
> properly.
>
> Currently I am calling SetScrollSize in WM_SIZE event, after the base
> class gets a crack at it. This works, but it is not the best place to
> put it because everytime I resize the Window, the scrollbars get
> reset.
>
> In what event is it recommended to call SetScrollSize() if I know the
> sizes at compile time?
>
> BTW: CScrollWindowImpl is very cool. Much more flexible and simple
> than the MFC CScrollView.
>
(Continue reading)

Tim Tabor | 4 Sep 2001 16:44
Picon
Favicon

RE: OT: COM Threading Question

> -----Original Message-----
> From: Menningen, Kevin [mailto:kmenningen@...]
> Sent: Friday, August 17, 2001 10:04 AM

> 
> Since my thread procedure does not have a message pump, then by using the
> same pointer in both apartments I'm really treating it as multithreaded,
> right? 

How are you calling CoInitialize[Ex] on the thread?

// tim

dohays | 4 Sep 2001 16:57

RE: OT: COM Threading Question

Hi Kevin:

Sounds like you have it about right --- not having a message pump would 
cause you to freeze in an STA --- as messages would not be getting 
serviced and the call will block.

You might be getting away with the pointer method, but I wonder how long 
it will run or how stable it will be. It will probably depend on how the 
thread procedure is being used (serially or truly multi-threaded). Also 
-- if you don't have "state" data inside the thread procedure, then you'll 
tend to get away with more. 

You could implement 'Lock / UnLock' code to force the procedure to only 
handle access by a single thread (everybody gets in-line). It is quite 
difficult to use a debugger to understand what is really going on -- as 
the timing gets all screwed up in the break-points and you'll see th 
debugger "jump around" depending on which process is calling it.

When I'm really trying to understand thread usage, I'll create a "Logging 
Database" ---- with messages/records created upon Thread Procedure entry, 
processing and exit. I make sure my database keeps track of who the 
caller is (via process id) as well as time/date. It's kind of fun to be 
able to "see" how the procedure is really being used -- instead of running 
blind. Depending on how you've implemented your COM apartments, you 
might find that everything is being handled in a queued/serial fashion -- 
which could explain why you're not having any problems at the moment.

Anyway . . . hope these ideas help a bit.

Dale
(Continue reading)

Mark Kramer | 4 Sep 2001 20:31
Picon
Favicon

RE: Japanese Windows and WTL dialogs

Try changing the FONT in the rc file from "MS Sans Serif" (the default
in the resource editor) to "MS Shell Dlg 2". You'll have to do this "by
hand"
in a text editor as "MS Shell Dlg 2" is not available via the resource
editor.

The other FONT you might try is "Microsoft Sans Serif".

Hope that helps,
Mark

-----Original Message-----
From: Alexander Fedorov [mailto:alexf2000@...] 
Sent: Friday, August 17, 2001 8:09 AM
To: wtl@...
Subject: [wtl] Japanese Windows and WTL dialogs

Hi,
Has anybody expirienced any problems with printing of japanese
characters in WTL-based dialogs? In my case it looks like WTL have some
problem with proper font for controls. It does not replacing font from
what was specified in resource editor to font which is capable to show
Japanese hieroglyphs. My solution for it is to check if double byte
charset is enabled, if yes, obtain defaul GUI font and set this font for
all controls like edit, list, tree etc. Can anybody suggest something
better?

Sincerely, Alexander Fedorov

To unsubscribe from this group, send an email to:
(Continue reading)

tlandry | 5 Sep 2001 10:30

Why doesn't CMapScrollImpl support MM_ISOTROPIC?

Is there some reason that CMapScrollImpl doesn't support MM_ISOTROPIC 
or MM_ANSITROPIC map modes?

I am trying to implement a zoom feature, and I am still deciding the 
best way to implement it.

Thanks,

Ted

Tim Tabor | 5 Sep 2001 22:54
Picon
Favicon

RE: How to get a reference to the CMainFrame in one of its children?

This is risky business - the child shouldn't need to
be that intimate with all of its ancestors. You can get 
the top windows with

CWindow::GetTopLevelWindow

and

CWindow::GetTopLevelParent

// tim

> -----Original Message-----
> From: new2wtl@... [mailto:new2wtl <at> yahoo.com]
> Sent: Monday, August 20, 2001 1:55 PM

> CWindow l2Wnd, rightWnd, topSplitWnd;
> CMainFrame mainFrame;
> l2Wnd.Attach(GetParent()); 
> rightWnd.Attach(l2ScaleViewer.GetParent());
> topSplitWnd.Attach(rightWnd.GetParent());
> mainFrame.Attach(topSplitWnd.GetParent());

Brock Davis | 5 Sep 2001 23:01
Picon
Favicon

RE: How to get a reference to the CMainFrame in one of its children?

Well, the easy way is to cheat and create a global pointer to CMainFrame.
Then you can call any method you want.

Or, since you have the window handles, you can post a user message to the
mainframe window handle. But then you have to define a user message for
each method you want to invoke.

On how you are attaching to the different objects, I think that works fine
to create an instance of the standard CWindow object, but will not allow you
to get any special methods, such as SetStatusBar. In other words, when you
finally attach "mainFrame.Attach(topSplitWnd.GetParent());" this will not
give you an instance of your real mainframe, so you will not have the
m_statusBar object. I'm probably mistaken, but I think that is true.

Brock Davis
brock@...
yahoo! id: brocktriplets
404-495-3440
-----Original Message-----
From: new2wtl@... [mailto:new2wtl <at> yahoo.com]
Sent: Monday, August 20, 2001 1:55 PM
To: wtl@...
Subject: [wtl] How to get a reference to the CMainFrame in one of its
children?

I have a child control that's a great-great-grand child of its
CMainFrame (it's inside a CWindow that's inside another CWindow
that's inside a CSplitterWindow that's inside the CMainFrame). What I
need is whenever the user moves the mouse over it, the status bar
displays certain information. In CMainFrame I have a method:
(Continue reading)

Tim Tabor | 5 Sep 2001 23:05
Picon
Favicon

RE: Japanese Windows and WTL dialogs

Are you having problems with text in the dialog
box or text in the controls or both?

// tim

> -----Original Message-----
> From: Alexander Fedorov [mailto:lamer2000@...]
> Sent: Thursday, August 16, 2001 10:46 PM
> 
> Hi,
> Has anybody expirienced any problems with printing of japanese 
> characters in
> WTL-based dialogs? 

Tim Tabor | 5 Sep 2001 23:21
Picon
Favicon

RE: How to get a reference to the CMainFrame in one of its children?


> -----Original Message-----
> From: Brock Davis [mailto:brock@...]
> Sent: Wednesday, September 05, 2001 5:01 PM

> Or, since you have the window handles, you can post a user message to the
> mainframe window handle. But then you have to define a user message for
> each method you want to invoke.

This would get my vote. Otherwise, you can define a single 
message AM_GETTHIS which returns a pointer to the object.

// TIM


Gmane