Howdy from Texas!
***************
I am happy to announce that with the help of some fine people from this forum, "VeggieSquares" (//http://) has been brought to reality in a pre-release version.  It is called "VeggieSquares" (http://ebasic-aurora.com/forums/index.php?topic=4307.msg33996#msg33996) because it incorporates my simple "Four-Square" gardening method I developed for my purposes.  It is born of the collective wisdom of many gardeners.  
You can download the latest zip file at the bottom of this post (http://ebasic-aurora.com/forums/index.php?topic=4307.msg33996#msg33996).
***************
I am attempting to develop a freeware drag and drop game for children and I'm coming up a dry well.  Here is what I want to do...
- Drag and object (icon or button) from a frame on the right on to an uncolored outline (coloring book type) background graphic on the left, like a park bench in a park. 
- Drag another object next to the first dropped object.
- When the second object is dropped next to the first, a lookup is done in a table and a comic book style balloon pops up as if the first object was speaking to the second object.
FYI - the "table" could be a DB, an *.ini file or just a series of CASE statements.
There is more, but if I could get this much going, then I think I can make the rest work.  
Thanks in advance!
Calvin
			
				To start off, I would setup a 2D DirectX screen.  Load your graphics (outlines and benches etc.) as sprites, and draw them to the screen in the appropriate locations.    When the user clicks on an object to drag it, have it redraw the sprite at the current mouse position.  When the user releases the mouse button, do a collision detection between the object and the outline, and if they match correctly, then draw the sprite in the same location as the outline.  Draw your word bubble sprite, and write the appropriate text in the bubble from the table.
All of the commands needed to do these are in the Users Guide, in the 2D programming section.
			
			
			
				Quote from: ZeroDog on November 25, 2010, 12:25:59 PM
To start off, I would setup a 2D DirectX screen.  Load your graphics (outlines and benches etc.) as sprites, and draw them to the screen in the appropriate locations.    When the user clicks on an object to drag it, have it redraw the sprite at the current mouse position.  When the user releases the mouse button, do a collision detection between the object and the outline, and if they match correctly, then draw the sprite in the same location as the outline.  Draw your word bubble sprite, and write the appropriate text in the bubble from the table.
All of the commands needed to do these are in the Users Guide, in the 2D programming section.
Thank you very much!  This gives me a vector to go to work now. :)
			
 
			
			
				Hi CodeTRUCKER,
Attached to this message is a short example of what you were after.
I knocked it up rather quickly so it probably isn't what you would call an example of beautiful code, although it should give a rough idea.
It pretty much does exactly as ZeroDog described.
Hope this helps.
Kian
			
			
			
				Quote from: Kian on November 26, 2010, 03:06:25 PM
...
Hope this helps.
Kian
Thanks, Kian.  This helps a lot!  I think I might be able to make it from here once I figure out everything that is going on.
~ CT
			
 
			
			
				Thanks from me too Kian!  Gives me a great idea for a Xmas card.
			
			
			
				Hi Kian,
Many thanks for your giving me a boost!  The project is coming along nicely with less than five days to go.  I will post back here when the project is ensconced.
Kian, in your program there is a strange anomaly in your original code that did not show up due to the large scale and oddly, it only occurs when dragging the sprite "down" or "up" (the "y" ).  It does not occur when dragging in the "x" direction?!  Specifically, you can see the 1x1 pixel sprite drag farther and farther behind the tip of the mouse "arrowhead" as you drag down. 
To test this... 
-  Execute the app, but don't click on the dalmatian just yet.
-  First, move the mouse up toward the dog's left eye as this is the "highest" clear spot where the anomaly can be observed.
-  Locate the 1x1 sprite just above the mouse tip.
-  Click and drag the mouse down as far as you can and observe how the space between the sprite and mouse tip increases as you drag down and decreases as you drag back up
You may want or need to... 
<> Set the screen resolution to 800x600
<>The "detect=CREATESPRITE(1,1,1)" to "detect=CREATESPRITE(10,10,1)
... to view the anomaly more easily.  I have spent several hours attempting unravel (debug) this mystery, but to no avail, hence this post seeking assistance.  My biggest puzzlement is why does this only happen in the "y" direction and not the "x?"  Most peculiar.
Thanks again for the help!
Calvin
{Edits}
Ok, I have discovered the anomaly occurs on the @IDMOUSEMOVE event.  It is not necessary to drag anything to see the anomaly, but dragging will highlight it.
It also appears to be a cascading error.  The dog's eye, the 10x10 sprite and the mouse tip all spread evenly while dragging down. 
			
				Hi Kian,
Could you also please explain the rationale for the code in red below?
SUB handler
    IF @MESSAGE=@IDMOUSEMOVE
   cx=@MOUSEX
   cy=@MOUSEY
   cy=cy+(30*cy/570)
   cx=cx+(8*cx/772)
   MOVESPRITE detect,cx,cy
   ENDIF
Thank you,
Calvin
			
			
			
				Calvin
comment out the two lines in red that you posted above and see what that does to your anomaly.
LarryMc
			
			
			
				Quote from: Larry McCaughn on December 27, 2010, 01:31:40 PM
Calvin
comment out the two lines in red that you posted above and see what that does to your anomaly.
LarryMc
Thanks for the help, LarryM.  Good call!
OK, that prevented the 10x10 from changing position on the dog, but it did not remove the anomaly.  The spread still occurs between the 10x10 and the mouse tip.
 FYI - I'm persuaded it is somehow connected to the @IDMOUSEMOVE since the remaining anomaly ("spread" between 10x10 and the mouse tip) occurs by just moving the mouse down (not dragging).  
			
 
			
			
				Update - ignore this and see following post.
Kian
Hi again,
The code you highlighted in red was a quick and dirty fix.
When @IDMOUSEMOVE is called, the client area coordinates returned also include the borders around the window.
This is what causes the offset. This varies according to OS and setup.
To rectify this, paste the following code at the start of your program:
$include "windowssdk.inc"
int wintop = GetSystemMetrics(SM_CYSIZE)
int winbot = GetSystemMetrics(SM_CYSIZEFRAME)
int ydiff=wintop+winbot
int xdiff=GetSystemMetrics(SM_CXSIZEFRAME)
In the red section, change the '30' to 'ydiff' and the '8' to 'xdiff'.
Hopefully this should (crosses fingers) sort out the problem.
I've tried this on XP and 7 and it seems to work, but let me know if it doesn't.
Kian
(revised code attached)
Update:
I've done a few more tests and it still seems to create a slight "spread" depending on the OS, although not as great as before. Going from one edge of the screen to the other (either vertically or horizontally) there is still a shift of a couple of pixels, although any changes I make seem to be amplified on XP compared to 7.
You could always make it full screen and none of this would be a problem.
			
			
			
				Scratch that last post. Still too inconsistent.
As often happens, IWbasic provides us with the perfect tool, if only we look hard enough for it.
Using 'GETCLIENTSIZE' gives the exact client area, so giving the correct ratio to adjust by.
(see attached code).
Kian
 ::)
			
			
			
				Quote from: Kian on December 28, 2010, 05:12:09 AM
Scratch that last post. Still too inconsistent.
As often happens, IWbasic provides us with the perfect tool, if only we look hard enough for it.
Using 'GETCLIENTSIZE' gives the exact client area, so giving the correct ratio to adjust by.
(see attached code).
OK the "anomaly"... IT"S FIXED!  Yea!
Ah!  "GETCLIENTSIZE" ... you don't say?  I was using "GETSCREENSIZE."  Live and learn. 
In my general debugging I also discovered some @MOUSEX and @MOUSEY where cx and cy should have been. GIGO lives!
I guess I'll forge ahead now.  A LOT to do before New Years!
Thank you for the help.
Calvin
			
 
			
			
				@Kian and Anyone Else,
The formula code worked great until a MENU was added, then it was necessary to modify it.  Given the MENU was 25 pixels high the following mod (in red) fixed it up.  The salient point is if menus, statusbar or anything else which subtracts from the vertical screen real estate is in the window an adjustment will be necessary.  GETCLIENTSIZE does not "see" these, AFAICT.
SUB handler
    IF @MESSAGE=@IDMOUSEMOVE
   cx=@MOUSEX
   cy=@MOUSEY
   cy=cy*600/(h-25)
   cx=cx*800/w
   MOVESPRITE detect,cx,cy
   ENDIF
I've attached the files below.  
@Anyone - Try both *eba files and drag down from inside the dog's eye to see the effect.
			
			
			
				Tried downloading zip file but file will not extract  ???
Could you upload again?
You may want to use : 
$include "windowssdk.inc"
int menusize=GetSystemMetrics(SM_CYMENU)
to find the menu height as on my system the menu bar is only 20 pixels deep.
Kian
P.S. - I've tried inserting a menu (the example from the user guide) into my program and 'GETCLIENTSIZE' DOES take this into account.(under XP and 7)
			
			
			
				Hi,
This worked for me - Win XP SP3. Added autodefine "off" and changed
the bitmap variables to POINTERS (as it says in the help file!). A lot of the
variables were undefined
Worked as I think you wanted it to...
Brian
			
			
			
				Hi Folks,
Next issue... I have tried a number of permutations of DRAWSPRITE, FLIP(), etc., but to no level of success.
What I am trying to do is to move any vegetable sprite object I click on will be brought to the front which will allow me to drop it *on* another sprite object, covering it.
The present behavior is... 
<> I drag a "squash" on to the "gardenplot" 
<> Then I drag a "tomato" under the "squash"  
The desired behavior is...
<> I drag a "squash" on to the "gardenplot" 
<> Then I drag a "tomato" on top of the "squash"  
What's the command to "move to front" where sprites are concerned?
Thanks for the help,
Calvin
			
			
			
				Quote from: Kian on December 28, 2010, 10:01:16 AM
Tried downloading zip file but file will not extract  ???
Could you upload again?
Sure, but let me take a look at Brian P.'s *.eba
QuoteYou may want to use : 
$include "windowssdk.inc"
int menusize=GetSystemMetrics(SM_CYMENU)
to find the menu height as on my system the menu bar is only 20 pixels deep.
Kian
Thanks for the tip.  I had used a pixel measuring tool, but your method should be more precise.
QuoteP.S. - I've tried inserting a menu (the example from the user guide) into my program and 'GETCLIENTSIZE' DOES take this into account.(under XP and 7)
Hmmm.... if that is the case, I wonder why does my behavior NOT work without the adjustment? 
			
 
			
			
				Another mystery solved,Calvin.
Finally managed to extract with Tugzip  :)
In your version, the menu was built AFTER getting the client size. This is why it did not show up.
Re: the sprite order, they are layered in the order that they are drawn.
Do the sprites you are using always appear in the same order (ie tomato over squash)?
If this is so then it is possible to just draw them in the order they are required with the 'top' one drawn last.
If this is not the case, you could assign each sprite a 'depth' variable which determines the order.
Kian
			
			
			
				Quote from: Brian Pugh on December 28, 2010, 10:18:57 AM
Hi,
This worked for me - Win XP SP3. Added autodefine "off" and changed
the bitmap variables to POINTERS (as it says in the help file!). A lot of the
variables were undefined
Worked as I think you wanted it to...
Brian
Thanks, Brian.
As far as "...(as it says in the help file!)...." is concerned, I apologize for any inconvenience, but I abhor lazy people as much as anyone.  Unfortunately, I am experiencing more "senior moments" than I really care to admit.  Anytime I request help it is usually hours (if not days) of digging in examples, forum searches and help files myself before I seek assistance. I learn best this way, even it it is painful sometimes.  Frankly, I can't get my brain around what you are talking about "pointers," but I'll dig into that too and see if I can understand.  It's my fault I waited so long to begin (and discover how much I had forgotten), but life has kept me busy and away from coding.  FYI - I am against a deadline of 2010-12-31 23:59, so I am very appreciative of any assistance.  Please be patient with me, but know I am attempting to honor your contributions.
Calvin
			
 
			
			
				Quote from: Kian on December 28, 2010, 11:08:10 AM
Another mystery solved,Calvin.
Finally managed to extract with Tugzip  :)
I'm glad it worked!  FYI - I used Winrar.
QuoteIn your version, the menu was built AFTER getting the client size. This is why it did not show up.
Ok, Thanks!  I'll give it a whirl.  My "guesses" at what goes where has been something of a trial.
QuoteRe: the sprite order, they are layered in the order that they are drawn.
Do the sprites you are using always appear in the same order (ie tomato over squash)?
If this is so then it is possible to just draw them in the order they are required with the 'top' one drawn last.
If this is not the case, you could assign each sprite a 'depth' variable which determines the order.
Kian
It's the latter, but it has to be dynamic.  Every time the child "clicks" on a vegetable, it needs it to "move to front."  I'll try some experiments with your suggestion.
Calvin
			
 
			
			
				A very simple example:
In the original version the dog sprite was always drawn behind the hydrant.
In this version, whichever sprite is being dragged is assigned the highest 'depth' value.
Line 7 sets up an array to hold pointers to each sprite.
This array is then used by the sprite drawing routine (lines 88-92) to draw them in the correct order. The initial order is set in lines 47-52.(The outlines always remain at the back)
When a sprite is clicked on to be dragged, the array is changed to reflect this, bringing the selected item to the top(lines 133-136 for dog, lines 147-150 for hydrant).
 When using more than the 2 sprites here this could be done with a loop which moves all the sprites above the selected one down in priority.
e.g.
depth[0]=tomatoOL
depth[1]=squashOL
depth[2]=cucumberOL
depth[3]=tomato
depth[4]=squash
depth[5]=cucumber
If tomato is clicked on:
squash->depth[3]
cucumber->depth[4]
tomato->depth[5]
Kian
			
			
			
				FYI - I did the unthinkable.  Please see here (http://ebasic-aurora.com/forums/index.php?topic=4365.msg33828#msg33828).
I will take another shot at it later and thanks to all for the help!
Calvin
			
			
			
				Hey, Calvin!
I wasn't having a dig at you. I've never used this Direct stuff before myself. When I loaded
up your example, it threw an error with the bitmaps. So THEN I looked at the help file
My programming is a bit like yours, 90% looking up examples, and 10% writing code
Unfortunately, at work today . . .
Brian
			
			
			
				Quote from: Brian Pugh on December 29, 2010, 02:13:38 AM
My programming is a bit like yours, 90% looking up examples, and 10% writing code
As is mine!
LarryMc
			
 
			
			
				Quote from: Brian Pugh on December 29, 2010, 02:13:38 AM
Hey, Calvin!
I wasn't having a dig at you. I've never used this Direct stuff before myself. When I loaded
up your example, it threw an error with the bitmaps. So THEN I looked at the help file
My programming is a bit like yours, 90% looking up examples, and 10% writing code
Unfortunately, at work today . . .
Brian
I'm glad to hear it.  I didn't consider your exclamation point would have been aimed at you.  I guess I'm under more pressure than I realized, but life goes on.  Thanks for clarifying and making me feel not so alone in the "10% Club!" :)
Calvin
			
 
			
			
				FYI - Someone on another forum has pointed out that the latest versions of Windows have a "Previous Versions" tab in the Properties of every file!  So, I'm a bunch behind my time, but at least I'm not all the way back at the beginning.   ;D
Well, wish me luck.  I'm back to work!
			
			
			
				Quote from: Larry McCaughn on December 29, 2010, 07:59:25 AM
Quote from: Brian Pugh on December 29, 2010, 02:13:38 AM
My programming is a bit like yours, 90% looking up examples, and 10% writing code
As is mine!
LarryMc
Hmmm... given that you must spend at least a couple hours a day on coding (based on how prolific you are) that means you could only get two hours of sleep!
No wonder you're so prolific!  ;D
			
 
			
			
				You'd be surprised how much time I soend on my computer.
With my health the way it is I'm not able to do much else. ;)
LarryMc
			
			
			
				Since I understand what you mean about health limitations, maybe not....
You see, I have my computers and monitors on one of those hospital rolling tables which I snug up to my La-Z-Boy recliner where I peck away from the time I get up until I go to bed almost every day.  I occasionally will spend a couple of hours with my family by rolling away the table, but I still stay in my "Boy."  I do try to get outdoors a couple of times a day for a few minutes.  Fortunately, I live in the country, so the outdoors does beckon me from time to time.  I am hoping 2011 will allow the realization of some family businesses, including some maturity to my coding skills.  My New Year's Resolution is to structure my computer activities and discipline my self to play at the right time and work when it's time to work.
Hmmm... that reminds me.  I better get back to coding. 
			
			
			
				Yoohoo?
Is their any advantage to migrating what I have left of my app from EmergenceBASIC to IWBASIC?
I tried, but it keeps telling me "No input files specified."
I'm lost on this.  FYI - I will post a zip of my app as soon as I fix a couple of know issues. 
			
			
			
				Tell me the steps you went through when you tried to "migrate" your app.
And which version of IWB do you have?
LarryMc
			
			
			
				Quote from: Larry McCaughn on December 29, 2010, 04:44:17 PM
Tell me the steps you went through when you tried to "migrate" your app.
LarryMc
- I selected "Saved As" which populated the dialog as "veggiesquares.eba".
- Changed the file typ to "All Files"
- Used the same file name ("veggiesquares") and added the "iwb" extension to save it as "veggiesquares.iwb".
			
 
			
			
				to make sure I understand (based upon what you said).
The app you've been working on consists of one single file named "veggiesquares.eba".
It is not part of a project.
you saved the file with the iwb extention.
you closed ebasic, started the IWB IDE and opened the "veggiesquares.iwb" file (and not a project).
you clicked on the exe toolbar button and told it to compile it as a windows.exe.
The reason I go through all those steps is because I've only seen the error message "No input files specified."
when I've created a project and tried to compile it before I've added any source files to the project.
LarryMc
			
			
			
				Quote from: Larry McCaughn on December 29, 2010, 05:53:06 PM
...
It is not part of a project.
...
LarryMc
BINGO!  Again, somehow without me knowing (understanding?) how it occurred, there *was* a project open?!?
Thanks again!  Back to work!
			
 
			
			
				Next issue: showing/hiding Radio Buttons
I'm pretty sure the 3rd digit in the hex is 5=visible and 4=invisible, please explain what is the purpose of the hex or the rest of the hex in red below.  I have tried to find info in the ebooks and help, but if it is there, I can't find it.
CONTROL w,@RADIOBUTTON,"Radio1",250,200,70,20,0x40000009,RADIO_1
CONTROL w,@RADIOBUTTON,"Radio2",250,300,70,20,0x50000009,RADIO_2
Also, on execution the window appears with nothing in it and in a few seconds just closes.  Why?
FYI - my deadline is 27 hours away.  Please help!
Thanks for the help!
Calvin
/*
This program has two radio buttons and two checkboxes.
When a checkbox is checked the respective radio button
should be visible.  When a checkbox is unchecked the 
respective radio button should hide.
*/
DEF w as window
DEF RADIO_1 as INT
DEF RADIO_2 as INT
CONST STATIC_3 = 3
CONST STATIC_4 = 4
CONST CHECK_5 = 1
CONST CHECK_6 = 2
OPENWINDOW w,0,0,500,500,@NOAUTODRAW|@MINBOX,NULL,"Radio Button Test",&handler
CENTERWINDOW(w)
' IF(ATTACHscr(w,scrW*0.95,scrH*0.90,TRUE) < 0)
IF(ATTACHSCREEN(w,500,500,TRUE) < 0)
    MESSAGEBOX w,"Couldn't create DirectX window","Error"
    CLOSEWINDOW w
    END
ENDIF
CONTROL w,@RADIOBUTTON,"Radio1",250,200,70,20,0x50000009,RADIO_1
CONTROL w,@RADIOBUTTON,"Radio2",250,300,70,20,0x50000009,RADIO_2
CONTROL w,@STATIC,"Hide First",180,46,70,20,@CTLSTCSIMPLE|0x5000010B,STATIC_3
CONTROL w,@STATIC,"Hide Second",175,102,70,20,@CTLSTCSIMPLE|0x5000010B,STATIC_4
CONTROL w,@CHECKBOX,"Check1",400,100,70,20,0x50000003,CHECK_5
CONTROL w,@CHECKBOX,"Check2",400,300,70,20,0x50000003,CHECK_6
SUB handler
	SELECT @MESSAGE
		CASE @IDCONTROL
			SELECT @CONTROLID
				CASE RADIO_1
					IF @NOTIFYCODE = 0
						/*button clicked*/
					ENDIF
				CASE RADIO_2
					IF @NOTIFYCODE = 0
						/*button clicked*/
					ENDIF
		CASE @IDCONTROL
			SELECT @CONTROLID
				CASE CHECK_5
					IF @NOTIFYCODE = 0
						/*button clicked*/
					ENDIF
				CASE CHECK_6
					IF @NOTIFYCODE = 0
						/*button clicked*/
					ENDIF
			ENDSELECT
			ENDSELECT
	ENDSELECT
	
	IF @MESSAGE = @IDCLOSEWINDOW 
		CLOSESCREEN
		CLOSEWINDOW w
    ENDIF
RETURN
ENDSUB
			
			
			
				Too many errors to explain them all.
This will do what you want, as I understand it.
/*
This program has two radio buttons and two checkboxes.
When a checkbox is checked the respective radio button
should be visible.  When a checkbox is unchecked the 
respective radio button should hide.
*/
DEF w as window
CONST  RADIO_1 =5
CONST  RADIO_2 =6
CONST STATIC_3 = 3
CONST STATIC_4 = 4
CONST CHECK_5 = 1
CONST CHECK_6 = 2
	OPENWINDOW w,0,0,500,500,@NOAUTODRAW|@MINBOX,NULL,"Radio Button Test",&handler
' IF(ATTACHscr(w,scrW*0.95,scrH*0.90,TRUE) < 0)
	IF(ATTACHSCREEN(w,500,500,TRUE) < 0)
		 MESSAGEBOX w,"Couldn't create DirectX window","Error"
		 CLOSEWINDOW w
		 END
	ENDIF
	CONTROL w,@RADIOBUTTON,"Radio1",250,200,70,20,0,RADIO_1
	CONTROL w,@RADIOBUTTON,"Radio2",250,300,70,20,0,RADIO_2
	showwindow w,@swhide,RADIO_1
	showwindow w,@swhide,RADIO_2
	CONTROL w,@STATIC,"Hide First",180,46,90,20,0,STATIC_3
	CONTROL w,@STATIC,"Hide Second",175,102,90,20,0,STATIC_4
	CONTROL w,@CHECKBOX,"Check1",400,100,70,20,0,CHECK_5
	CONTROL w,@CHECKBOX,"Check2",400,300,70,20,0,CHECK_6
	WAITUNTIL w = 0
	END
SUB handler
	SELECT @MESSAGE
		case @IDCREATE
			CENTERWINDOW(w)
		CASE @IDCONTROL
			SELECT @CONTROLID
				CASE RADIO_1
					IF @NOTIFYCODE = 0
						/*button clicked*/
					ENDIF
				CASE RADIO_2
					IF @NOTIFYCODE = 0
						/*button clicked*/
					ENDIF
				CASE CHECK_5
					IF @NOTIFYCODE = 0
						if getstate(w,CHECK_5)=0
							showwindow w,@swhide,RADIO_1
						else
							showwindow w,@swshow,RADIO_1
						endif
					ENDIF
				CASE CHECK_6
					IF @NOTIFYCODE = 0
						if getstate(w,CHECK_6)=0
							showwindow w,@swhide,RADIO_2
						else
							showwindow w,@swshow,RADIO_2
						endif
					ENDIF
			ENDSELECT
		case @IDCLOSEWINDOW
			CLOSESCREEN
			CLOSEWINDOW w
	ENDSELECT
RETURN
ENDSUB
LarryMc
			
			
			
				The one thing you have to remember when using those hex numbers generated by the dialog editor:
Some of the bits are automatically generated internally by the parser so that you changing the hex value manually really have no effect.
For you see, in the real world of WINDOWS an IWBasic button,radiobutton,checkbox, and groupbox are really a windows'  BUTTON.
And it's the automatic handling of the proper bits that allows them to work the way they are implemented in IWB.
LarryMc
			
			
			
				This is the way I probably would have coded it.
More than one way to skin a cat.
/*
This is the way I would have coded it
*/
	window w
	enum ctrls
		RADIO_1 =1
		RADIO_2 
		STATIC_3
		STATIC_4 
		CHECK_5
		CHECK_6 
	endenum
	OPENWINDOW w,0,0,500,500,@NOAUTODRAW|@MINBOX,NULL,"Radio Button Test",&handler
' IF(ATTACHscr(w,scrW*0.95,scrH*0.90,TRUE) < 0)
	IF(ATTACHSCREEN(w,500,500,TRUE) < 0)
		 MESSAGEBOX w,"Couldn't create DirectX window","Error"
		 CLOSEWINDOW w
		 END
	ENDIF
	CONTROL w,@RADIOBUTTON,"Radio1",250,200,70,20,0,RADIO_1
	CONTROL w,@RADIOBUTTON,"Radio2",250,300,70,20,0,RADIO_2
	showwindow w,@swhide,RADIO_1
	showwindow w,@swhide,RADIO_2
	CONTROL w,@STATIC,"Hide First",180,46,90,20,0,STATIC_3
	CONTROL w,@STATIC,"Hide Second",175,102,90,20,0,STATIC_4
	CONTROL w,@CHECKBOX,"Check1",400,100,70,20,0,CHECK_5
	CONTROL w,@CHECKBOX,"Check2",400,300,70,20,0,CHECK_6
	WAITUNTIL w = 0
	END
SUB handler
	SELECT @MESSAGE
		case @IDCREATE
			CENTERWINDOW(w)
		CASE @IDCONTROL
			SELECT @CONTROLID
				CASE RADIO_1
					IF @NOTIFYCODE = 0
					ENDIF
				CASE RADIO_2
					IF @NOTIFYCODE = 0
					ENDIF
				CASE CHECK_5
					IF @NOTIFYCODE = 0
						showwindow w,getstate(w,CHECK_5),RADIO_1
					ENDIF
				CASE CHECK_6
					IF @NOTIFYCODE = 0
						showwindow w,getstate(w,CHECK_6),RADIO_2
					ENDIF
			ENDSELECT
		case @IDCLOSEWINDOW
			CLOSESCREEN
			CLOSEWINDOW w
	ENDSELECT
	RETURN
ENDSUB
LarryMc
			
			
			
				Quote from: Larry McCaughn on December 30, 2010, 08:51:06 PM
The one thing you have to remember when using those hex numbers generated by the dialog editor:
Some of the bits are automatically generated internally by the parser so that you changing the hex value manually really have no effect.
For you see, in the real world of WINDOWS an IWBasic button,radiobutton,checkbox, and groupbox are really a windows'  BUTTON.
And it's the automatic handling of the proper bits that allows them to work the way they are implemented in IWB.
LarryMc
Ok, does this means I don't have to use them, right?
LarryM, - I know I've said it before, but I have to thank you again for your mentorship!  It's nice having the helping hand!
Calvin
			
 
			
			
				Quote from: CodeTRUCKER on December 30, 2010, 10:08:23 PM
Quote from: Larry McCaughn on December 30, 2010, 08:51:06 PM
The one thing you have to remember when using those hex numbers generated by the dialog editor:
Some of the bits are automatically generated internally by the parser so that you changing the hex value manually really have no effect.
For you see, in the real world of WINDOWS an IWBasic button,radiobutton,checkbox, and groupbox are really a windows'  BUTTON.
And it's the automatic handling of the proper bits that allows them to work the way they are implemented in IWB.
LarryMc
Ok, does this means I don't have to use them, right?
Yes and no.
For the basic defaults no - they are taken care of internally.
For additional features you have to add flags. - In the dialog editor you can select a control and right click select properties and click a checkbox to add a feature and the hex number will be changed accordingly.
An throughout the help file window/controls section there are descriptions for numerous constants you can use for style flags.
LarryMc
			
 
			
			
				Hello LarryM,
I have to admit I am unclear about how the code works in the [Your Preferred Code] (second example), but I'll take a guess.  
Ok, if I understand the following correctly and given these do exactly the same thing, I think? 
In this first example, [Your Initially Suggested Code], everything s pretty straight forward.  @NOTIFY of CHECK_5 is being tested against the default value of @NOTIFY being "off."  Then state (condition) of CHECK_5 is tested.  If CHECK_5 is *not* selected, the *HIDE* the radio button, RADIO_5.  Otherwise *SHOW* the radio button.   
[Your Initially Suggested Code]
...
01   CASE CHECK_5
02      IF @NOTIFYCODE = 0
03         IF GETSTATE(w,CHECK_5)=0
04            SHOWWINDOW w,@SWHIDE,RADIO_1
05         ELSE
06            SHOWWINDOW w,@SWSHOW,RADIO_1
07                  ENDIF
08               ENDIF
...
Now in the following [Your Preferred Code] line 23 below it looks like IWBASIC makes the assumption the default state of the check box is "unchecked" and therefore, the visibility of RADIO_1 is *hidden*.    Given this, it seems that *if* the default condition (GETSTATE) of CHECK_5 (unchecked) is not true (checked), THEN the opposite of the default is true and the radio button, RADIO_1 is made visible.   Essentially, everything is assumed to be "off" so only the coding for the opposite of the default is necessary. 
[Your Preferred Code]
...
21   CASE CHECK_5
22      IF @NOTIFYCODE = 0
23         SHOWWINDOW w,GETSTATE(w,CHECK_5),RADIO_1
24      ENDIF
...
I will test my theory , but I'd like your comments.  So, am I on the right track?
Thanks,
Calvin
			
			
			
				Quote from: CodeTRUCKER on December 31, 2010, 11:48:01 AM
Now in the following [Your Preferred Code] line 23 below it looks like IWBASIC makes the assumption the default state of the check box is "unchecked" and therefore, the visibility of RADIO_1 is *hidden*.    Given this, it seems that *if* the default condition (GETSTATE) of CHECK_5 (unchecked) is not true (checked), THEN the opposite of the default is true and the radio button, RADIO_1 is made visible.   Essentially, everything is assumed to be "off" so only the coding for the opposite of the default is necessary. 
[Your Preferred Code]
...
21   CASE CHECK_5
22      IF @NOTIFYCODE = 0
23         SHOWWINDOW w,GETSTATE(w,CHECK_5),RADIO_1
24      ENDIF
...
There are no ASSUMPTIONS made at all.
The equivalent of
SHOWWINDOW w,GETSTATE(w,CHECK_5),RADIO_1
is
int x = GETSTATE(w,CHECK_5)
SHOWWINDOW w,x,RADIO_1
So when the button is clicked the checkbox is checked to see if it is 0 or 1
That value is used to show or hide the radiobutton accordingly.
Since controls are normally visible when created  (and we want to make the 2 radiobuttons hidden initially)
we had to have the 
SHOWWINDOW w,@swhide,RADIO_1in the beginning.
The equivalent of 
SHOWWINDOW w,@swhide,RADIO_1
is
SHOWWINDOW w,0,RADIO_1
LarryMc
			
 
			
			
				Rats.  I thought I was starting to understand some things.  If it wasn't for all the other "I feel like a dunce" posts on the forum, I'd go sit in a corner. :)
Ok, I'll try again after I digest your comments.  
Thanks,
Calvin
			
			
			
				Additional comment
I hope it is not the 21   CASE CHECK_5
22      IF @NOTIFYCODE = 0
that is confusing you.
controls send notification messages to the parent window.
those two lines are saying we are checking the notification message sent to window w's message handler from the CHECK_5 checkbox.
The notification code we are checking for is a click which happens to have a value of 0
We could also check for a double-click, got focus, or lost focus.
CONST BN_CLICKED = 0
CONST BN_DBLCLK = 5
CONST BN_SETFOCUS = 6
CONST BN_KILLFOCUS = 7
21   CASE CHECK_5
22      IF @NOTIFYCODE = BN_CLICKED 
23         SHOWWINDOW w,GETSTATE(w,CHECK_5),RADIO_1
 or
21   CASE CHECK_5
22      select @NOTIFYCODE 
            case  BN_CLICKED 
23            SHOWWINDOW w,GETSTATE(w,CHECK_5),RADIO_1
            case  BN_SETFOCUS
            case  BN_KILLFOCUS 
            case  BN_CLICKED 
         endselectMy visual designer has a ton of those messages already defined for the user as well as the style flags(hex values we were talking about earlier)
LarryMc
			
			
			
				Hello,
How do I make sprites visible and invisible?
I have tried searching in the help, but I keep getting "No topics found" for searches.  What terms should I be searching for?
FYI - I am making various sprites visible only when a radio button is selected.  When radioA is selected, spriteA is visible and spriteB is hidden.  When radioB is selected, spriteA is invisible and spriteB is seen. 
Thank you,
Calvin   
			
			
			
				you just moved into an area I can't help you with - I don't mess with sprites and such.
But my initial thought is that you have to redraw everything and not draw the ones you want hidden.
But I can be totally wrong.
I will see if I can find anything in all my accumulated stuff.
LarryMc
			
			
			
				Looking here on the forums I think I;m right.
Programming 7 - A Direct X Window Project. 
 (http://ebasic-aurora.com/forums/index.php?topic=4079.msg31923#msg31923)
This is from something Graham wrote for CBasic but the principle is the same.
QuoteThe main new item is that we are looking for @IDDXUPDATE messages.
These are messages which start to flow as soon as the DX screen is opened.
Each time a @IDDXUPDATE message is received, the program will call another subroutine (in this example called 'Update'), which contains all the processing to calculate new speeds and directions, and move objects and sprites in the scene.
Each update, the entire screen background, text, and sprites are all re-drawn.  This happens very quickly, and you can acheive much more than 100 frames redrawn a second - so the action appears continuous.
So, if all the sprite drawing is in a subroutine you just need to keep track of which sprites you don't want drawn.
LarryMc
			
				@LarryM - Thanks for the info on @IDDXUPDATE.  I will attempt to work through and digest Graham's offering (tutorial) later.  Unfortunately, I am out of time and have to resort to making copies of the background bitmap and exchanging them as needed.  This will work fine for the present because none of the sprites that needed to be visible/invisible perform any movement.
Can you please direct me to where I can find information on showing/hiding background bitmaps in the Help?  Again, my searches are not very fruitful.
Thanks,
Calvin
[Edit - I just found the "LOADIMAGE" command, but feel free to comment.]
			
			
			
				Just a guess but it would seem that since you mentioned bitmaps that they all would be treated like sprites; it's just for a background the sprite would be the size of the screen and drawn first with all the other sprites on top,
That's what I guess based upon a first reading of the 2D/sprites section of help file.
Like I said, I don't mess with that stuff.
LarryMc
			
			
			
				Hi LarryM,
I thought about that too, but I can't get it to work with the paltry knowledge of IWBASIC I possess at present.   I am out of time and will have to present what I have by midnight.  Which reminds me...
Happy New Year!
			
			
			
				Hello,
A word of "Thanks!" for all the assistance in helping me get this program in place by 1/1/11!  Due to the aforementioned snafu, it wasn't as polished or as feature rich as I had designed, BUT it was accomplished on a usable level.
Take care,
Calvin
			
			
			
				Hello,
For all those that helped me in the genesis of this project, here is a pre-release version of my freeware app, "VeggieSquares!"
Feel free to download and try it out.  Let me know what you and your children (grandchildren?) think about it.
Thank you,
Calvin (aka "CodeTRUCKER")
			
			
			
				FYI - It has come to my attention there is some confusion about my app above....  
For the record the zip is from an executable not created in IWBASIC.  My original IWBASIC code was ported by a benefactor (who has required me to keep their identity anonymous) to a 4GL language. 
Although this forum is for IWBASIC, my posting the app (ported and completed in the other language by "Anonymous") was intended as a gesture of courtesy to those who helped me bring my original IWBASIC version to birth and without whose help the genesis would have been a trial, indeed.  I posted in this forum, so they could see their efforts were not in vain.  Thank you to you all!  :)   
Since this app is no longer an IWBASIC project, any inquiries should be directed to myself via PM.
Fair winds,
Calvin