OpenEuphoria

1. SWITCH problem - need thoughts

• Posted by jessedavis Apr 15, 2016
• 1716 views

Version 4.01.00 Windows 7 pro

I have just spent many hours trying to figure this one out. It just doesn't make sense to me (!). I include the code however only the switch block needs attention. "cat_sel_cancel_btn" (also called "cancel btn" in the printout) is a constant defined at the beginning of the program and the value is printed just after it is set as line 1 in printout. line 2 is the value just after entering the procedure. Line 3 is the value of a global atom set by the event handler which I also set evntownr to to remove any possible change in EventOwner affecting this test. Lines 4 & 5 are the values of "cancel btn" further down the switch. All looks OK. Now, when one arrives at "case cat_sel_cancel_btn then" (you will notice that evntownr and cat_sel_cancel_btn are equal) it should execute this case block, printing something with "point 5" in it; however, it continues to the "case else" and now the value of the CONSTANT "cat_sel_cancel_btn" HAS CHANGED! In the following code pf() is a print procedure which does nothing but print what's in the argument. I rewrote the code to use if/elsif statements instead of using switch blocks. It works perfectly. Now, I didn't think about this at the time (brain dead!) but, I had this very same problem earlier in the program with another switch statement. Replaced that one with if/elsif and moved on. In any event I think SWITCH has a real problem. It seems to have been plagued with problems since its introduction. Please, point out my error, just one word will do!

Thanks & Regards, jd

Here is the printout:

line #1  point a - cancel btn  => 9247618 
line #2  point 1 - cancel btn  => 9247618 
line #3  Event owner @ point 2A  => 9247618 
line #4  Point 2B evntownr  => 9247618 
line #5  point 2C - cancel btn  => 9247618 
line #11  cancel btn @ point 6A  => 9247616  <====  Here is the problem! 
line #12  Point 6B evntownr  => 9247618 
 

global constant cat_sel_cancel_btn = Control(Button,"CANCEL",200,125,75,35) 
	pf(cat_sel_cancel_btn,"line #1  point a - cancel btn => ")	 

Switch block in question:

-------------------------------------------------------------------------------- 
 
public procedure service_category(atom box)		--box is the event owner 
							--which is the col 7 box in grid 
sequence box_txt = GetText(box) 
atom evntownr 
	pf(cat_sel_cancel_btn,"line #2  point 1 - cancel btn => ") 
	set_cat_dialog_visibility(True) 
	while True do 
		WaitEvent()			        --only two things can happen "cancel Button" or 
							--a category picked.  Everything else is ignored. 
		evntownr = EventOwner	                --a global returned by a procedure elsewhere 
		if Event = Click then 
			pf(EventOwner,"line #3  Event owner @ point 2A => ") 
			pf(evntownr,"line #4  Point 2B evntownr => ") 
			pf(cat_sel_cancel_btn,"line #5  point 2C - cancel btn => ") 
			switch evntownr do 
				case cat_box then   
					pf(cat_box,"line #6  point 3 - cat_box = ") 
					pf(evntownr,"line #7  evntownr => ") any_key() 
					sequence cat_txt = GetItem(cat_box) 
					pp(cat_txt) 
					SetText(box,cat_txt) 
					pp(cat_txt) 
					set_cat_dialog_visibility(False) 
				case cat_sel_cancel_btn then 
					pf(cat_sel_cancel_btn,"line #8  cancel_btn @ point 5A = ") 
					pf(box,"line #9 Point 5B box = ") 
					pf(evntownr,"line #10 evntownr => ") any_key() 
					set_cat_dialog_visibility(False) 
				case else 
					pf(cat_sel_cancel_btn,"line #11  cancel btn @ point 6A => ") 
					pf(evntownr,"line #12  Point 6B evntownr => ") 
					any_key() 
			end switch 
		end if	 
	end while 
end procedure 
 
-------------------------------- 

3. Re: SWITCH problem - need thoughts

• Posted by xecronix Apr 15, 2016
• 1664 views

Also, does the following code work on your dev environment?

constant ctrl1=8247618 
constant ctrl2=9247618 
constant ctrl0=0 
 
atom evntownr=ctrl2 
switch evntownr do 
  case ctrl1 then 
    puts(1, "CASE ONE 8247618") 
  case ctrl2 then 
    puts(1, "CASE TWO 9247618") 
  case else 
    puts(1, "CASE THREE Uhh... what?") 
end switch 
 
puts(1, "\n") 
 

I played with this in both compiled and interpreted modes and it worked as expected each time.

-Xecronix

5. Re: SWITCH problem - need thoughts

• Posted by jessedavis Apr 15, 2016
• 1692 views

Thanks for your reply. Further information.

"4.1.0 development (6300:57179171dbed, 2015-02-02 14:18:53)"

pf() is just a printing procedure that prints whatever is inside the parenthesis pair. It's for quick debugging.

------------------------------------ 
--print routine for tests 
-- 
 
 
public procedure pf(atom nbr,sequence txt = "") 
 
printf(1,"%s => %d\n",{txt,nbr}) 
printf(fn,"%s => %d\n",{txt,nbr})          --this is a log file fn is global 
end procedure 
-------------------------------------- 

The following code works as expected:

include std/console.e 
 
constant ctrl1=8247618  
constant ctrl2=9247618  
constant ctrl0=0  
sequence cases = {ctrl1,ctrl2,ctrl0} 
integer fn = open("test_5.txt","w") 
 
for i = 1 to 3 do 
  
    atom evntownr=cases[i] 
    printf(fn,"Test %d\n",i)  
 
    switch evntownr do  
    case ctrl1 then  
        puts(fn, "CASE ONE 8247618\n")  
    case ctrl2 then  
        puts(fn, "CASE TWO 9247618\n")  
    case else  
        puts(fn, "CASE THREE Uhh... what?\n")  
    end switch  
end for  
 
puts(1, "\n\nend...\n")  
any_key()  

Test 1 
CASE ONE 8247618 
Test 2 
CASE TWO 9247618 
Test 3 
CASE THREE Uhh... what? 

Returning to the original problem:

Note the values I printed out and that the constant changed while INSIDE the Switch block. Thus-->

line #5  point 2C - cancel btn  => 9247618  
line #11  cancel btn @ point 6A  => 9247616  <====  Here is the problem! Between these two lines the value has changed.  Something would have to have the ability to assign a new value 
                                                    to a constant.  I have noticed that the value always changes by either 2 or 4.     

I can't say that it's the switch block at fault BUT, the value of the constant cat_sel_cancel_btn changed from just before the switch statement and the case where it is tested for. This behavior is NOT possible. The switch mechanism is passive. You can easily see this by following the point markers I left and their appearance in the printout. I ran the program with no changes 10 times. In 8 of the runs the value changed. In two case it did not change; however, the switch statement did not catch it. It just ended up in the else case.

For now I'm going to go with the if/else coding. I know it works. I'll report if I find something.

Thanks, jd

7. Re: SWITCH problem - need thoughts

• Posted by SDPringle Apr 16, 2016
• 1608 views

This is a known issue in Euphoria 4.1. This is not an issue in Euphoria 4.0. I invite you to use Euphoria 4.0 instead. I also think your post shows a much smaller and compact version of an example. I would like you to post it to ticket 944. Remove the Syntatic sugar provided by 4.1 and compile the latest sources of 4.0 so you don't get bit by the bugs in 4.0.5.

The ticket number is 944. It is available at http://openeuphoria.org/ticket/944.wc

SD Pringle

9. Re: SWITCH problem - need thoughts

• Posted by jimcbrown (admin) Apr 17, 2016
• 1575 views

EuWinGui on 4.x is a strange setup.

EuWinGui has a closed source (C?) library that was written for 3.x or earlier, and it uses the C interface from that version (e.g. include/euphoria.h et al.), which is not compatible with 4.0.0 or later. (Attempts to pass 4.0.0 objects directly to 3.1.1 result in a machine level exception.) Then the euphoria side passes euphorian objects directly with E_OBJECT, E_SEQUENCE, E_ATOM, or E_INTEGER.

To get it to work, I added an extra layer, written with Euphoria 3.1.1 and compiled against it. The Euphoria side (now 4.x) takes the euphoria object and uses sprint() and allocate_string() to turn it into a valid C string, which is passed to the 3.1.1 layer. THe 3.1.1 layer takes the C string, turns it into an Euphorian string, then uses value() to reconstruct the Euphorian object. Then that object is passed to the closed source (C?) library.

Return values work the same way. The Euphoria object returned by the closed source library is taken by the 3.1.1 layer and turned into a C string, then that is passed to the 4.x layer which turns it back into an Euphorian object again.

That said, if memory serves correctly, EuWinGui was actually written for Euphoria 2.3 or 2.4, so there might be some subtle incompatibility between the 2.x include/euphoria.h and the 3.x include/euphoria.h that is causing problems. Also, there are some values, such as nan and inf, which can't be passed back and forth with the sprint()/value() method. Somehow one of the edge cases might be getting hit here.

With tinEWG, it's all open source and no extra C library layer, so it wouldn't have these sort of problems.

I don't think the original author is supporting EuWinGUI anymore, so I'd recommend to everyone who wants to continue to use a similar API to migrate to tinEWG ASAP.