How do I center text in an edit line?

Marty,

Edit lines only have left justification.

Try using an edit box instead. Take off the horizontal and vertical scroll bars, and set justification to center. Resize the control as needed. Hope this helps.

Kim Ruane

WinWin Solutions Inc.

www.winwinsol.com

If the EDITLINE is a Symbolic, then you can probably use an OCONV type with justification of T#nn like @ANS=FMT(yourstuff,"T#30"). If its an entry field, then it won't work. I assume you wouldn't want it to either.

Don Miller

Or worse still - have a CHAR or CHANGED handler using Utility TEXTRECT to continually measure the pixel width of the content and pad with the appropriate amount of spaces, and also update the SELECTION accordingly.

- Oystein -

Hey Marty, good question! I sure wish there was an easy answer. Like mentioned already, I used an edit box so I could center text. I really wonder why there isn't an option for centering.

And still i wonder how windows does certain things. Like windows explorer has those heading "buttons"? interesting how they work. Its those little things that get me thinkin.

Or set up a device context, write the text to the device context as a device independent bit map and position the bitmap within the editline at the rightmost extremity…

The Sprezzatura Group

World Leaders in all things RevSoft

Yeah, but for speed don't forget to double-buffer and bit-blit it. Hmm.. there's always the DirectX API if you really need high performance…But then you'd need a 32-bit thunking layer ….

—————————–7d03011d303f6–

Agent C my foot! Group member undercover alert!

- Oystein -

Richard,

And still i wonder how windows does certain things. Like windows explorer has those heading "buttons"? interesting how they work. Its those little things that get me thinkin.

You mean buttons that lie flat and dull in a panel until the mouse cursor passes over, when they sort of spring forward in bright colour? The EXAMPLES app has …uh… an example of that. See the EXAMPLE_MAIN window.

In EXAMPLE_MAIN the implementation of this feature is done with

- one large bitmap containing a picture of all the buttons in their "rest state"

- on top of that one invisible PUSHBMP (button with BMP images) for each button

- some programming that makes a button visible while the cursor passes above it (the windows' WINMSG handler)

- some programming necessary for that WINMSG handler to work

(the windows' CREATE handler).

Do it! It's fun!

- Oystein -

Sprezz,

How does one set up a device context?

Or how does one get the device context for an existing control?

How can one write text to a device context?

Can one do stuff like this entirely in OI, with Windows API calls?

- Oystein -

Yep, yep and yep…

There are various API calls for dealing with all this such as GetDC(), ReleaseDC(), SelectObject(), DeleteObject() etc etc etc and it's possible to use all of these from inside OI. The Slist Workspace uses them to draw in the gasbar.

However, what you have to remember is that the Presentation Server knows nothing about what you're drawing and so if your window gets covered by another or resized for example the PS won't draw it back in for you. …so you have to do this yourself, which means responding to WM_PAINT messages.

However, all windows messages that you can intercept are only POSTED to you, not SENT, which means there might be a delay in the drawing, and if the engine is busy doing something else (like a SELECT ) then the Basic+ code you need to do the drawing won't get run until later and you get a blank bit.

It can work, I've done it to implement self-sizing tabs in a window, but really the best way to do any of this is too…..subclass and do all your drawing in a DLL ( sorry Don

Dr C

Dear Mr Dr Agent C,

There are various API calls for dealing with all this such as GetDC(), ReleaseDC(), SelectObject(), DeleteObject() etc etc etc and it's possible to use all of these from inside OI.

So I've gathered. I hope it's just a trivial thing that keeps it from working here. I just made a posting about my problems: . I'd be grateful if you could spare the time to look at it.

However, what you have to remember is that the Presentation Server knows nothing about what you're drawing and so if your window gets covered by another or resized for example the PS won't draw it back in for you. …so you have to do this yourself, which means responding to WM_PAINT messages.

I know. I've already found an old posting by Cameron with some details.

However, all windows messages that you can intercept are only POSTED to you, not SENT, which means there might be a delay in the drawing, and if the engine is busy doing something else (like a SELECT ) then the Basic+ code you need to do the drawing won't get run until later and you get a blank bit.

That's useful information. But it's probably all right for my purposes now.

It can work, I've done it to implement self-sizing tabs in a window, but really the best way to do any of this is too…..subclass and do all your drawing in a DLL ( sorry Don

That's beyond me for now.

Thanks so far.

- Oystein -

Øystein Reigem,

Humanities Information Technologies,

Allégt 27,

N-5007 Bergen,

Norway.

Tel: +47 55 58 32 42.

Fax: +47 55 58 94 70.

oystein.reigem@hit.uib.no

Home tel/fax: +47 56 14 06 11.

Aaarrggh!

dbakke@srpcs.com

SRP Computer Solutions

View this thread on the forum...