Computer Science Canada Confusing Problem With View.UpdateArea (Era of War) |
Author: | BioHazardousWaste [ Sat Feb 14, 2004 5:12 am ] |
Post subject: | Confusing Problem With View.UpdateArea (Era of War) |
As suggested I have been using the View.UpdateArea command to deal with graphics and create animations in Era of War. It was working nicely until I wanted the user to input a command. The problem is that the user cannot see what they are typing. I tried setting the window back to nooffscreenonly mode, but that screwed up the lines seperating the three sections of my window, and is not very nice switching the type back and forth so often. So I need to know what I can to do so that the user can see what they are typing. |
Author: | TheXploder [ Sat Feb 14, 2004 10:09 am ] |
Post subject: | |
I think the main reason is that View.UpdateArea updates only that one specific area unless you're typing within the View.UpdateArea you are not going to see it.... you could make another View.UpdateArea for the text... [Edit] Now that I think about it... That's not the problem... [Edit] It's becuse it doesn't do any updates while it gets an input... Try using fork... |
Author: | BioHazardousWaste [ Sat Feb 14, 2004 11:52 am ] |
Post subject: | |
Not exactly sure how that would work... could you give me an example please? |
Author: | Cervantes [ Sat Feb 14, 2004 12:09 pm ] |
Post subject: | |
if you were to use View.Update (no area part) does it work? I can't really think of why without seeing the code. You can PM me all or part of the code and I'll take a look |
Author: | TheXploder [ Sat Feb 14, 2004 12:24 pm ] | ||
Post subject: | |||
no I tryed View.Update, it doesn't work, only way I found is this, but its so, slow, maybe gotta add some delay... ohh, ya, delay 15 works
|
Author: | BioHazardousWaste [ Sat Feb 14, 2004 12:30 pm ] |
Post subject: | |
Thanx man, that seems to work allright... you forgot to include an exit when statement , but I got that figured out. |
Author: | Cervantes [ Sat Feb 14, 2004 12:40 pm ] |
Post subject: | |
Xploder how could you be so cruel as to suggest processes....... they suck bio did you get it to work my way or xploder's cursed processes way? |
Author: | BioHazardousWaste [ Sat Feb 14, 2004 12:43 pm ] |
Post subject: | |
Quote: Xploder how could you be so cruel as to suggest processes....... they suck
bio did you get it to work my way or xploder's cursed processes way? Xploder's cursed processes worked ... but processes will lag the game up will they not? |
Author: | Cervantes [ Sat Feb 14, 2004 12:48 pm ] |
Post subject: | |
Yes, horribly. |
Author: | TheXploder [ Sat Feb 14, 2004 1:50 pm ] |
Post subject: | |
ok I think I know another way... use graphic text... and you can update that. I do know that processes suck, and I told you already. View.Update doesn't work because it waits for you to press enter, it doesn't update while you type, that is the problem... [Edit] So getch might work, better... |
Author: | Tony [ Sat Feb 14, 2004 1:52 pm ] |
Post subject: | |
no no no what you need to do is create a console window. Basically just another distinct View.UpdateArea where text is displayed. You would just need to be able to minimize/maximize that area so it doesn't get in the way... Or keep it on the game screen with a timer. |
Author: | recneps [ Sun Feb 15, 2004 1:29 pm ] | ||
Post subject: | |||
Tony's on to something there, you could have a separate window open
then just have the user input info into that window, like HL console (except its separate window) |
Author: | sport [ Sun Feb 15, 2004 3:03 pm ] | ||
Post subject: | |||
will not work, because get is a predefined word so jus change get to any other word.[/quote] |
Author: | Cervantes [ Sun Feb 15, 2004 5:23 pm ] |
Post subject: | |
I don't think that's the best way to do it... that involves having to click twice (once to switch windows and once to click the button or whatever). Also it doesn't look that great. |
Author: | shorthair [ Sun Feb 15, 2004 10:03 pm ] |
Post subject: | |
Albert einstein didnt look that great , but he re defined physics , dude we need a working game not a pretty one ,thast why we belive in updates and fixes , letsnot get hooked on GUI when there is a game to be made |
Author: | BioHazardousWaste [ Mon Feb 16, 2004 1:51 pm ] | ||
Post subject: | |||
Quote: dude we need a working game not a pretty one ,thast why we belive in updates and fixes
Amen shorthair... but as for the idea, I think it will work. I tried this:
and it returned a negative value for Y when I clicked below the window... so could I not use the same thing? when the user clicks on the button on the second window, it will return a negative value, but I still know where the mouse is, so I can call the appropriate function. Yes? No? Maybe? |
Author: | Cervantes [ Mon Feb 16, 2004 3:39 pm ] |
Post subject: | |
Yes you can do that. I don't understand why no one thinks View.UpdateArea is good. The code that you sent me bio works fine once you make it all fit on the screen (ie. not having huge locates such as 37 and 48 (for the row). |
Author: | BioHazardousWaste [ Mon Feb 16, 2004 3:50 pm ] |
Post subject: | |
Both ideas seem to work fine, but the advantage that a second window has, is that it will be very easy to hide or show that window: e.x. if the user wanted battle statistics they could be put there (e.x. Hvy Tank missed, Light tank hit for 40 dmg). But that is later, I need to get the game made first |
Author: | Tony [ Mon Feb 16, 2004 5:12 pm ] |
Post subject: | |
actually having a council window run on the side with stats and messages would be really cool (easier to debug too)... the only problem would be the constant switching back and forth between the two... and say if the windows switch and the user clicks on the play window before windows switch back, output will end up in the wrong window |
Author: | BioHazardousWaste [ Mon Feb 16, 2004 6:05 pm ] |
Post subject: | |
Quote: actually having a council window run on the side with stats and messages would be really cool (easier to debug too)...
the only problem would be the constant switching back and forth between the two... and say if the windows switch and the user clicks on the play window before windows switch back, output will end up in the wrong window I got the idea from NWN (Never Winter Nights) and really liked it. But, I don't think that getting the right window would be a problem. Before any output is sent, if I put the Window.Select command there should never be an error, from what I understand anyways. |