OpenEuphoria

2. Re: Edit text fields in child windows

• Posted by CChris <christian.cuvier at agriculture.gouv.fr> Apr 23, 2007
• 521 views

Chris McConnell wrote:
> 
> I am a new user of Euphoria and I have tried to use child windows.
> 
> Has anyone come up with a solution to the problem where selecting a text edit
> field in a child window with a mouse will not cause the field to become in
> focus.
> I see in the forum where other programmers have had the issue but I did not
> find a fix. 
> 
> I can set tab stops and advance through the text edit fields but I have not
> been able to select a field in a child window with a mouse click.
> 
> TIA


I  tried various things, and came up with the following:
1/ the window procedure associated to a window with the WS_CHILD flag
doesn't send the right messages to an edit field when the latter gets mouse
clicks (and it actually gets them). Edit fields are supposed to appear in
top level windows or in dialog boxes.

2/ Edit fields are antiquated components that existed before win 3.0. This
may explain 1/, and why 1/ doesn't have an easy fix.

3/ But after all, RichEdit controls are more recent and don't depend so much
on the parent, so use RichEdit instead of EditText in child windows.

4/ But you'll have to create them with the right styles, and using findText()
will fail on NT based systems (will be fixed in the next version of win32lib).
Does the code in http://www.listfilter.com/EUforum/m13681.htm
help? See if it works for you.

CChris

4. Re: Edit text fields in child windows

• Posted by Rad <radhx at rediffmail.com> Apr 25, 2007
• 514 views

CChris wrote:
> 
> I  tried various things, and came up with the following:
> 1/ the window procedure associated to a window with the WS_CHILD flag
> doesn't send the right messages to an edit field when the latter gets mouse
> clicks (and it actually gets them). Edit fields are supposed to appear in
> top level windows or in dialog boxes.
> 
> 2/ Edit fields are antiquated components that existed before win 3.0. This
> may explain 1/, and why 1/ doesn't have an easy fix.
> 
> 3/ But after all, RichEdit controls are more recent and don't depend so much
> on the parent, so use RichEdit instead of EditText in child windows.
> 
> 4/ But you'll have to create them with the right styles, and using findText()
> will fail on NT based systems (will be fixed in the next version of win32lib).
> Does the code in <a
> href="http://www.listfilter.com/EUforum/m13681.htm">http://www.listfilter.com/EUforum/m13681.htm</a>
> help? See if it works for you.
> 
> CChris

Hi CChris,

As I would like to use RichEdit in place of the EditText control, is there a way
to limit text to specified characters within one line at the same time not
allowing to move to next line within RichEdit by pressing RETURN key?

I used "Limit Text To:" property in IDE to set max characters, but I can press
Return key and continue on next line, which I want to avoid.

Regards,
Rad.

6. Re: Edit text fields in child windows

• Posted by Dan Moyer <danielmoyer at prodigy.net> Apr 25, 2007
• 499 views

Dan Moyer wrote:
> 
> Rad wrote:
> > 
> > CChris wrote:
> > > 
> > > I  tried various things, and came up with the following:
> > > 1/ the window procedure associated to a window with the WS_CHILD flag
> > > doesn't send the right messages to an edit field when the latter gets
> > > mouse
> > > clicks (and it actually gets them). Edit fields are supposed to appear in
> > > top level windows or in dialog boxes.
> > > 
> > > 2/ Edit fields are antiquated components that existed before win 3.0. This
> > > may explain 1/, and why 1/ doesn't have an easy fix.
> > > 
> > > 3/ But after all, RichEdit controls are more recent and don't depend so
> > > much
> > > on the parent, so use RichEdit instead of EditText in child windows.
> > > 
> > > 4/ But you'll have to create them with the right styles, and using
> > > findText()
> > > will fail on NT based systems (will be fixed in the next version of
> > > win32lib).
> > > Does the code in <a
> > > href="http://www.listfilter.com/EUforum/m13681.htm">http://www.listfilter.com/EUforum/m13681.htm</a>
> > > help? See if it works for you.
> > > 
> > > CChris
> > 
> > Hi CChris,
> > 
> > As I would like to use RichEdit in place of the EditText control, is there a
> > way to limit text to specified characters within one line at the same time
> > not
> > allowing to move to next line within RichEdit by pressing RETURN key?
> > 
> > I used "Limit Text To:" property in IDE to set max characters, but I can
> > press
> > Return key and continue on next line, which I want to avoid.
> > 
> > Regards,
> > Rad.
> 
> Rad,
> 
> I can't be sure if this will help, nor can I fill in the details right now,
> but:
> 
> I think you could set a trap for the enter/return key in some event like
> w32HKeyDown, or w32HKeyPress, for the RichEdit,
> and then make the routine have a return if the enter key pressed, 
> which should/might make the enter key be ignored.
> (ie, if keypressed equal "enter" key, then return from procedure)
> 
> Dan Moyer


And here's a variation on above that uses Win32Lib "returnValue",
which might be the right way to do what you want,
from the Win32Lib documentation:

(just use VK_RETURN instead of VK_SPACE, and put in event for RichEdit 
instead of Button1 in example below)

-- prevent Button1 from seeing any space bar keys
procedure Button1_KeyDown( integer self, integer event, sequence parms) 
 integer keycode 
 integer shift
 
 keycode = parms[1] 
 shift = parms[2]
 if keycode = VK_SPACE then 
   -- set return value 
   returnValue( w32True ) 
 end if 
end procedure 
setHandler( Button1, w32HKeyDown, routine_id("Button1_KeyDown")) 

Dan Moyer

8. Re: Edit text fields in child windows

• Posted by Chris McConnell <chris at mc-data.com> Apr 25, 2007
• 518 views
• Last edited Apr 26, 2007

CChris wrote:
> 
> Rad wrote:
> > 
> > CChris wrote:
> > > 
> > > I  tried various things, and came up with the following:
> > > 1/ the window procedure associated to a window with the WS_CHILD flag
> > > doesn't send the right messages to an edit field when the latter gets
> > > mouse
> > > clicks (and it actually gets them). Edit fields are supposed to appear in
> > > top level windows or in dialog boxes.
> > > 
> > > 2/ Edit fields are antiquated components that existed before win 3.0. This
> > > may explain 1/, and why 1/ doesn't have an easy fix.
> > > 
> > > 3/ But after all, RichEdit controls are more recent and don't depend so
> > > much
> > > on the parent, so use RichEdit instead of EditText in child windows.
> > > 
> > > 4/ But you'll have to create them with the right styles, and using
> > > findText()
> > > will fail on NT based systems (will be fixed in the next version of
> > > win32lib).
> > > Does the code in <a
> > > href="http://www.listfilter.com/EUforum/m13681.htm">http://www.listfilter.com/EUforum/m13681.htm</a>
> > > help? See if it works for you.
> > > 
> > > CChris
> > 
> > Hi CChris,
> > 
> > As I would like to use RichEdit in place of the EditText control, is there a
> > way to limit text to specified characters within one line at the same time
> > not
> > allowing to move to next line within RichEdit by pressing RETURN key?
> > 
> > I used "Limit Text To:" property in IDE to set max characters, but I can
> > press
> > Return key and continue on next line, which I want to avoid.
> > 
> > Regards,
> > Rad.
> 
> 
> Limiting text length, ie the amount of characters, won't work, this is a
> feature of EditText controls.
> 
> I had posted the following test code:
> }}}
<eucode>
> constant Window1 = createEx( Window, "Window1", 0, Default, Default, 200, 140,
> 0, 0 )
> constant CWindow3 = createEx( Window, "", Window1, 56, 24, 200, 100,
> w32or_all({WS_CHILD}),
> 0 )
> openWindow(CWindow3, Normal)
> constant EditText4 = createEx( RichEdit, "EditText4", CWindow3, 8, 28, 48, 20,
> {w32or_all( {  WS_CLIPPINGCHILD,
> 	    	        WS_VISIBLE,
> 	    	        ES_AUTOHSCROLL,
> 	    	        WS_TABSTOP,
> 	    	        ES_SAVESEL,
> 	    	        WS_BORDER } )}
> , 0 )
> 
> WinMain( Window1,Normal )
> </eucode>
{{{

> Try it and see if this displays decently enough for your purpose. At least,
> it won't go to next line on pressing enter and won't display horizontal
> scroll bars. You can't remove some styles after creation, so be sure to
> create the control with the right styles.
> 
> Why do you need the parent window to be a child window? The only benefit
> this style gives you is auto clipping (wrt both parent and siblings), and I
> just can't figure how windows with edit controls benefit from that.
> Removing the style will enable you to use EditTexts as you initially
> intended.
> 
> CChris

I liked child windows because they are contained in the parent and close with
the parent. It is just a matter of preference. I am sure with some code the
window can be closed with what I consider a window parent if the style is
removed.

10. Re: Edit text fields in child windows

• Posted by CChris <christian.cuvier at agriculture.gouv.fr> Apr 29, 2007
• 502 views

Rad wrote:
> 
> CChris wrote:
> > 
> > Limiting text length, ie the amount of characters, won't work, this is a
> > feature of EditText controls.
> > 
> > I had posted the following test code:
> > }}}
<eucode>
> > constant Window1 = createEx( Window, "Window1", 0, Default, Default, 200,
> > 140, 0, 0 )
> > constant CWindow3 = createEx( Window, "", Window1, 56, 24, 200, 100,
> > w32or_all({WS_CHILD}),
> > 0 )
> > openWindow(CWindow3, Normal)
> > constant EditText4 = createEx( RichEdit, "EditText4", CWindow3, 8, 28, 48,
> > 20,
> > {w32or_all( {  WS_CLIPPINGCHILD,
> > 	    	        WS_VISIBLE,
> > 	    	        ES_AUTOHSCROLL,
> > 	    	        WS_TABSTOP,
> > 	    	        ES_SAVESEL,
> > 	    	        WS_BORDER } )}
> > , 0 )
> > 
> > WinMain( Window1,Normal )
> > </eucode>
{{{

> > Try it and see if this displays decently enough for your purpose. At least,
> > it won't go to next line on pressing enter and won't display horizontal
> > scroll bars. You can't remove some styles after creation, so be sure to
> > create the control with the right styles.
> > 
> > Why do you need the parent window to be a child window? The only benefit
> > this style gives you is auto clipping (wrt both parent and siblings), and I
> > just can't figure how windows with edit controls benefit from that.
> > Removing the style will enable you to use EditTexts as you initially
> > intended.
> > 
> > CChris
> 
> Thanks CChris & Dan,
> 
> Mouse Clicks worked on RichText within a Cwindow.
> Multiple lines issue also got solved with the code provided by CChris.
> For that, in IDE, instead of {w32or_all{}}, I had to use {...}.
> The "Limit text to" property is also working on RichText.
> 
> But now I have a new issue.
> To make focus pass to next control on pressing Enter or Tab key, I used
> following
> code (for all RichTexts)-
> 
> }}}
<eucode>
> procedure RichEdit41_onKeyUp (integer self, integer event, sequence
> params)--params
> is ( int scanCode, int shift )
> 	if find(params[1], {VK_RETURN, VK_TAB}) then
> 		putStream(self, StreamText, trim(getStream(self, StreamText))) -- to remove
> tab from the
> text
> 		if params[2] = 0 then
> 			tab_direction(self, 1)
> 		elsif (and_bits(params[2], ShiftMask) and params[1] = VK_TAB) then
> 			tab_direction(self, -1)
> 		end if
> 	end if
> end procedure
> setHandler( RichEdit41, w32HKeyUp, routine_id("RichEdit41_onKeyUp"))
> </eucode>
{{{

> 
> This code works fine as long as there is no other control between 2 (or more)
> RichTexts in a Cwindow.
> 
> Say if you have 3 fields in a Cwindow in following sequence -
> 
> field1 - RichText
> field2 - Combo
> field3 - RichText
> 
> When focus is on field1 and you press Enter/Tab key on field1, focus properly
> moves to field2.
> But when you again press Enter/Tab key on field2, instead of focus being moved
> to field3, it moves to field1.
> Looks like Enter/Tab key pressed on field2 is processed by Keyup procedure of
> field3.
> 
> Similar thing happens when Shift+Tab key is pressed.
> 
> Any suggestions?
> 
> Regards,
> Rad.

The following code is not very elegant, but I couldn't find any simple way
to prevent the RichEdit from seeing the tab key:

include win32lib.ew
constant
a=create(Window,"test",0,100,100,200,300,0),
b=create(Window,"child",a,10,10,180,280,WS_CHILD),
c1=create(RichEdit,"txt1",b,10,10,160,30,0),
c2=create(Combo,"",b,10,50,160,80,0),
c3=create(RichEdit,"txt3",b,10,130,160,30,0)

procedure p(integer id,integer event,sequence parms)
openWindow(b,Normal)
end procedure
setHandler(a,w32HActivate,routine_id("p"))

-- the following is a little ugly, but works.
-- It instructs the targetted control(s) to use 1 dialog unit wide tabs;
-- this is treated as 0 chars. 
-- Don't poke 0 instead, or you'd get the default 8 char tab stops
integer void
constant notabs=w32acquire_mem(w32new_memset(),Long)
poke4(notabs,1)
void=sendMessage(c1,EM_SETTABSTOPS,1,notabs) -- 1 = lParam -> uniform tab width
void=sendMessage(c3,EM_SETTABSTOPS,1,notabs)

procedure RichEdit41_onKeyUp (integer self, integer event, sequence params)
    if find(params[1], {VK_RETURN, VK_TAB}) then
-- added the following line, which disables the enter key, but not the tab :(
        returnValue(-1)
putStream(self, StreamText, trim(getStream(self, StreamText))) -- to
        remove tab from the text
        if params[2] = 0 then
            tab_direction(self, 1)
        elsif (and_bits(params[2], ShiftMask) and params[1] = VK_TAB) then
            tab_direction(self, -1)
        end if
    end if
end procedure
-- changed the event, as most controls hook WM_KEYDOWN rather than WM_KEYUP
setHandler( {c1,c3}, w32HKeyDown, routine_id("RichEdit41_onKeyUp"))

WinMain(a,Normal)

Is there a wide demand for this old style dialog box behaviour in a child
window? If so, there's going to be a need for a DialogBox control. No joy 
given how M$ designed the API. Actualy, most of the additions to the
structure handling system in win32lib I'm making have this as an ultimate
goal (I was considering a new Wizard control rather). Still, I had no plan
for doing just that, as it would require still more work.

CChris
PS for testers: I hope I can send a last version this long weekend. There
were hidden bugs in the previous one (w32memory.ew), and the whole nest blew
open.