[MaxIDE] IDE Find bug (Win32, Win64)
Archives Forums/BlitzMax Bug Reports/[MaxIDE] IDE Find bug (Win32, Win64)
| ||
| Haven't seen anyone report this yet. In at least the last two versions of BlitzMax (I believe; currently running 1.33), if I do a Find (Ctrl-F) in the IDE and type in something new, about half the time it says it could not find some random integer that seems to have nothing to do with the search string. Then if I run a Find again and type in the same thing, maybe it works next time or a third time. For instance, if I run a Find and type in "Market" (which definitely should be found) and hit enter, I might get "Could not find 264834". It doesn't seem to matter what is selected or what I am doing. It just won't work, and then after a few tries, it will. This happens on XP (x32), Vista x64, and Windows 7 x64. I develop on several systems and it happens on all. I haven't been able to check out any non-MS systems. I know it's minor but it's very frustrating for me. Please help! |
| ||
| Same here, I run into this intermittently. |
| ||
| Seb's aware of this one, but so far I think still unable to reproduce. I'm sure additional detailed reports on your setup & when it occurs would be appreciated... |
| ||
| Nothing special: Vista x64 SP2, US English release, 6GB RAM |
| ||
| Same here, doesn't matter what computer I run it on or what the specs are, aside from all being Windows. Another thing that happens is sometimes when I try to Find something, I get the results of the last Find I ran, instead of what I just typed in. It happens at all times when I am working inside the IDE; what I am doing otherwise doesn't seem to affect it. Sometimes it feels like if I slow down my typing in the Find box, that might help it succeed more often, like maybe I am going too fast for it; but I really can't be sure of that correlation. |
| ||
| Something weird must be happening to the stack and as I can't reproduce there isn't a lot I can do from my end. If someone experiencing this problem has MaxGUI and wouldn't mind trying out the following test-app (which attempts to replicate some of the behaviour): This should just print the text-field text out a million times when you hit the button, but if it isn't and is displaying numbers, let me know. This is such a long shot I know (it's hard enough making short reproducable examples when you can reproduce it in the main app, but if you can't even reproduce it there, the odds are very slim). :P |
| ||
| I have MaxGUI, and I get a compile error with this code: Duplicate identifier 'TIconStrip' in modules 'brl.maxgui' and 'maxgui.maxgui' Not sure what's going on there as my other MaxGUI programs work fine. Thanks for following up on this. I have 14000 lines of code and Find is my lifeline to getting around quickly. Since we're grasping at straws, could recompiling my modules ever have caused any such problem? Is there a config file or a cache somewhere I can change/delete? |
| ||
| @ Drackbolt: You shouldn't have a brl.mod/maxgui.mod directory. If you do, delete it, then try it again. @SebHoll: I ran it and, after it locked up my MaxIDE, I went through the output and everything was text. :) |
| ||
| I can't reproduce, but with keyboard only: Running MaxIDE, can creating the following 3 line program: ~0 [CtrlF Market] Search Market returns "could not find Market" [Enter CtrlF ~] Search ~ and get "could not find Market" My guess is you possibly have broken behavior of textfield filter callback, I tried to understand the change you have made to it. The translation layer is also a little scary as far as complexity goes. The use of StdErr for human readable debugging also is a bit of a surprise but thats a bit OT. |
| ||
| Hey Skid, Maybe it's late, but I'm having trouble trying to understand your post. I can't reproduce, but with keyboard only: So you're saying you can reproduce it with the keyboard, but not with the mouse? [CtrlF Market] Search Market returns "could not find Market" [Enter CtrlF ~] Search ~ and get "could not find Market" That's strange - it seems to work over here...  Also, I'm not sure that this is the same bug as the reported one (where the string is mysteriously converted into a number literal when it's passed between methods). See Grisu's output in the original dev team thread. My guess is you possibly have broken behavior of textfield filter callback, I tried to understand the change you have made to it. Which text-field are you referring to? The one in the Find window? That shouldn't even have a filter assigned to it... I should also mention that these bugs are reported for the version of MaxIDE that Mark shipped with v1.34 (which I believe is the same as the one packaged with v1.33) and so that would imply that it isn't caused by any of the tweaks I've made since then. So far, I've come to the conclusion that it is a MaxGUI.Win32MaxGUIEx bug as Grisu reported in the Dev Team thread that the exact same source file compiled against MaxGUI.FLTKMaxGUI on Windows doesn't exhibit this behaviour. The translation layer is also a little scary as far as complexity goes. Really? Under the hood it might be a little heavy (mainly so that it is resilient and modular), but I hoped the resulting API and actual usage would be easy-as-pie for MaxGUI coders to pick-up and implement. P.S. There have been quite a few commits this evening for MaxGUI and MaxIDE, addressing several bugs and inconsitencies, so you may wanna run another "SVN Update" soonish. |
| ||
| yes, keyboard only and it only does it some times, but I agree, unlikely to be related The translation comment was strictly from trying to follow the code on paper. Instead of testing anything I have been merely following the find requester code flow by stepping through the source mentally and found my myself a little confused at times. I'll rephrase the comment and say the new translation stuff is a lot more featured than I realized :) |
| ||
| The translation comment was strictly from trying to follow the code on paper, instead of testing anything I have been merely following the flow by stepping through the code mentally and found my myself a little confused at times. Fair enough - I've focused mainly on writing the user-docs. I should probs go through and comment that code before release. :-) I'll rephrase the comment and say the new translation stuff is a lot more featured than I realized :) Hehe! I'll take that very much as a compliment. :D @ Following the "Find Requester" code by hand. I asked Grisu to post the output of a test-build I sent him which tracked the strings as it propagated through the various functions in the code. This is what is sooo strange. The top one, it works perfectly. The bottom one - somehow the string gets modified between TOpenCode.Invoke() being called and the function being executed: TFindRequester.ShowFind( term$="Project" ) TFindRequester.Poll() find$= "Project" TOpenCode.Invoke( command=17, argument="Project" ) Argument is of type: String TOpenCode.FindNext(s$="Project") > 1. s$="Project", seek$="Project" > 2. s$="Project", l$="project", p=71 > 3. l$="project", p=71 > 4. l$="project", p=71 > 5. p=71, s$="Project", %1="Project" Wurde nicht gefunden '%1'. TFindRequester.ShowFind( term$="Project" ) TFindRequester.Poll() find$= "tunein" TOpenCode.Invoke( command=17, argument="197872" ) Argument is of type: String TOpenCode.FindNext(s$="197872") > 1. s$="197872", seek$="197872" > 2. s$="197872", l$="197872", p=71 > 3. l$="197872", p=-1 > 4. l$="197872", p=-1 > 5. p=-1, s$="197872", %1="197872" Wurde nicht gefunden '%1'.What goes into the function, doesn't come out... :S Again, only happens with MaxGUI.Win32MaxGUIEx. No reported incidents with MaxGUI.CocoaMaxGUI or MaxGUI.FLTKMaxGUI (either on Windows or Linux). :S |
| ||
| @Ked Huh... Well I guess I might have old and new ones installed at the same time. I'll look into that. Thanks a lot for the tip, but I don't want to fill up this area with more off-topic stuff. ;) EDIT: Well, I just tried the code now after a fresh install of latest BMax and MaxGUI (Thanks Ked), and it seems to return all strings correctly; but after it was done I went over to my code and searched for one word (that happened to be present in the viewable page) and immediately got an integer. I searched for "Starport" and received "Could not find '9832252'". Another EDIT: I hadn't used the mouse to click the Find button before, only used Ctrl-F. Can't seem to reproduce the problem using the button, but then again I can't test it as fast as the keyboard. |
| ||
| yes, keyboard only and it only does it some times, but I agree, unlikely to be related Just in case it does make a difference: I always use the CTRL-F keyboard shortcut, never use the GUI to initiate a search. Most of the time it works OK, occasionally it fails -- and when it fails, it'll fail over and over until I move the cursor around in the IDE (Typically just jump to the top, with CTRL-Home) |
| ||
| Same behavior for me. In fact, I often see the same integer again and again, even when searching for different things. Most of the time what seems to get me back to normal is jumping around with arrow keys, pgup/pgdown or ctrl-home or ctrl-end. But, I can also do the exact same behavior over and over again and still get the error. For instance, I can hit ctrl-end, ctrl-F, search for a particular string, and do the same thing 10 times in a row; probably 2 or three times out of that, the error will occur. So it seems more like some kind of random timing issue, if anything. That's the most I can find out. |
| ||
| I've never experienced the error reported (search string transformed in number). |
| ||
| I have confirmed this happens also with the GUI Find button. In addition, if a previous Find was run, sometimes instead of a random integer, a new Find will use the string from the previous search. |
| ||
| Leadwerks has posted a video but I still can't reproduce over here, or see what could be going wrong. |
| ||
| Hi, Can someone who is experiencing this issue please post the output of the following debug build of MaxIDE, for a session in which the bug occurs: MaxIDE Find Test For those who are unsure how, run the executable from the command prompt and use the '>' character to redirect STDOUT to a file, e.g. C:\> MaxIDE.exe > output.txtThanks! |
| ||
| Bump *anyone*? I only have a very narrow slot that I can have another quick look into this. |
| ||
| I haven't been able to replicate it yet myself -- it's very intermittent, but when it happens it's extremely annoying because it happens over and over again. No idea what triggers it initially, though. |
| ||
| Bumpty bump bump. |
| ||
| So far I cannot produce an error with the IDE you posted, although the official 1.36 IDE does still display the problem. |
| ||
| So far I cannot produce an error with the IDE you posted, although the official 1.36 IDE does still display the problem. That sounds like good news. Can you download MaxIDE v1.35 from the 'Product Updates' page, and let me know whether it is fixed in that version also? |
| ||
| Seems like you'll get unemployed... ;) No issues here so far (64 Bit). |
| ||
| *bump* I still have this problem with the current (1.37) version. And it's really annoying. I can't eighter reproduce any search errors with "MaxIDE Find Test". Running on Windows 7 Ultimate x64 |
| ||
| Hi, This has never, ever happened to me! How long does it typically take to happen? Seconds? Minutes? I've been going 'Ctrl F' for a while now and nothing... One thing to note - the find requester is initially filled in by 'WordAtPos' which looks to be a bit dodgy. If you're at the start of a line it returns the last word of the previous line so it can sometimes look like the findreq is being initialized with crud. |
| ||
| I still have this problem with the current (1.37) version. And it's really annoying. I can't eighter reproduce any search errors with "MaxIDE Find Test". The MaxIDE that Mark ships with BlitzMax is quite out of date, and is compiled against an old version of MaxGUI. Try updating to the new one on the Product Updates page, which other users have reported, has fixed the issue. @ Mark: Hint, hint :P |
| ||
| How long does it typically take to happen? Seconds? Minutes? It's really intermittent -- sometimes it would be OK for literally days on end, other times it would do it the very first time I search and continue to be broken for the next dozen search attempts as well. But like SebHoll mentioned: it appears to be fixed in the latest MaxIDE/MaxGUI builds... |
| ||
| Hi, > But like SebHoll mentioned: it appears to be fixed in the latest MaxIDE/MaxGUI builds... But what was the problem? Is it *really* fixed? |
| ||
| Hi, Seb, your MaxIDE 1.36 is missing the RanLibMods() step required under MacOS. I can't use it as the 'release' IDE until this is restored - see maxide.bmx source in the release package to see where it should be called. In your code, it's called when running the demo version for some reason, but that's it. |
| ||
| But what was the problem? At random times, the following would happen: 1) Edit -> Find (or CTRL-F) 2) Type a search word (e.g. "graphics") and hit the "find" button 3) Instead of jumping to the line containing 'graphics', the IDE would throw an error: "Could not find '147162635' (or some other semi-random number) 4) Subsequent searches would most likely return in similar errors, until the IDE was restarted. sometimes it would start working again for me after jumping the cursor to the first line sourcecode first, other times it did require the IDE restart until I could find anything again. Unfortunately, it's really intermittent -- it would work OK for hundreds of searches over multiple days time (with the computer shut down in between), and then it would screw up ten times in a row until restarting the IDE. Sometimes the error would pop up when searching immediately after launching the IDE, while other times it's fine for a few hours and then starts to misbehave. Really, really erratic. Is it *really* fixed? Since running SebHoll's latest MaxIDE release for a while, I haven't seen it happen anymore under windows... So if it didn't kill the bug, it's at least taking an extended vacation right now.. :-? |
| ||
| The MaxIDE that Mark ships with BlitzMax is quite out of date, and is compiled against an old version of MaxGUI. Try updating to the new one on the Product Updates page, which other users have reported, has fixed the issue. @ Mark: Hint, hint :P Hehe. Isn't it about time updating the MaxIDE version that ships with BlitzMax? That explains alot with all the fuzz about this bug. ;) The bug is probably fixed, but not in the BlitzMax release version. :P I just downloaded and updated the latest MaxIDE (v1.36) version. And it seems like it's working. Thanks Seb ! :) I'll test it, and report back if I can reproduce the bug. :) |
| ||
| see maxide.bmx source in the release package to see where it should be called Which release package? I thought the source of MaxIDE was no longer shipped with BlitzMax. I have to checkout a fresh copy from our MaxGUI SVN server whenever I upgrade. Can you e-mail me the source that you are using? > But like SebHoll mentioned: it appears to be fixed in the latest MaxIDE/MaxGUI builds... But what was the problem? Is it *really* fixed? Can't say for sure. As I couldn't reproduce the problem myself, it was a case of trying a few things, and putting out another build for people who were experiencing the issue to test. I remember adding a few "win32" directives around some functions which I always thought would be the likely source of the problem, but as I say, I wouldn't be able to guarantee whether it is actually fixed, or just delayed. |
| ||
| Hi, > At random times, the following would happen: That's the symptom - what was causing it? Is it in MaxGUI or the IDE? > I thought the source of MaxIDE was no longer shipped with BlitzMax. Your right - will send you my latest version (which hasn't changed for a while). I did do a release a while back of the 'latest' IDE and immediately hit the ranlibs issue - end result, a bunch of annoyed Mac users (without ranlibs, you can't compile anything) and me left worried about what else might have changed! |
| ||
| Mark, are you keeping up to date with MaxGUI versions or is a legacy version involved also? |
| ||
| Hi, Still on a slightly older version of MaxGUI I think. Will update for the next release, but it would be nice to have latest greatest IDE too...just need to test it more thoroughly this time I guess. |
| ||
| what was causing it? Is it in MaxGUI or the IDE? I assume MaxGUI, as the same problem hasn't been reported on Mac/Linux when linked against the Cocoa/FLTK drivers. If it's a memory corruption problem, we may have just been lucky with the other two though. :-/ Your right - will send you my latest version (which hasn't changed for a while). Coolio! I did do a release a while back of the 'latest' IDE and immediately hit the ranlibs issue - end result, a bunch of annoyed Mac users (without ranlibs, you can't compile anything) and me left worried about what else might have changed! Eeeekkk... Which release was that? I've been using the new MaxIDE on my Intel Mac for a few releases, and haven't had any problems building/compiling modules - does it only affect certain systems? What does ranlibs do? |
| ||
| immediately hit the ranlibs issue There's a problem if ranlib is run against ALL .a files in the mod directory tree. If you have win32 .a files in there, it will incorrectly "fix" those archives, breaking them for use with Win32 ar/ld. Obviously, this isn't a problem for most people, but if you happen to have a cross-compiler set up - i.e. where you can build Win32 apps directly on Mac - you then need to do a FULL rebuild of all the win32 modules. Which is a bit of a pain. Would it be possible only to run ranlib against a particular OS+CPU type, rather than everything? This problem is specific to the IDE, isn't it? |
| ||
| There's a problem if ranlib is run against ALL .a files in the mod directory tree. But what does ranlib actually do? I vaguely remember something about it being a PPC Mac only thing, or have I got my wires crossed? |
| ||
| It updates the contents table inside the archive (.a) file, so that the linker can find the functions it needs when it is building the executable. |
| ||
| Hi, OK, I think the story with ranlib is basically this (and note: this ONLY applies to the Mac): A timestamp is stored inside every archive file that says when the archive's 'table of contents' was last updated. This is pretty much legacy voodoo I think, as creating an archive sets the timestamp correctly as does updating it as far as I remember (not that bmx ever does - it just creates archives). However, if the timestamp inside an archive file does not match the timestamp of the archive file itself (I *think* this is the core of problem...), LD will *refuse* to link with it! And this can happen whenever an archive file is copied (possibly only from another machine?) or installed - ie: when a BlitzMax update is installed. The solution is to run ranlib on archive files which rebuilds TOC and resyncs timestamps. Or, you can do a rebuild all modules, but I still like having updates usable 'out of the box' so to speak. There is a BMK option that ranlibs everything in sight, and the IDE has a RanLibMods() function that calls it. In my version of the IDE, RanLibMods() is called somewhere inside the 'build documentation' step. My IDE here: http://www.blitzbasic.com/tmp/maxide.bmx Search for 'ranlibmods' (If ya can!) Hmm....just rebuilt my IDE with latest GUI and there appears to be an empter 'row' below the toolbar... |
| ||
| In my version of the IDE, RanLibMods() is called somewhere inside the 'build documentation' step. Cool - I've committed a new version of MaxIDE (v1.37) which should have the same behaviour as yours to the MaxGUI repo/product updates page. Also ran a quick DIFF and noticed that the NT check which you have was missing from the new version, so I added that in too. Hmm....just rebuilt my IDE with latest GUI and there appears to be an empter 'row' below the toolbar... See MaxGUI v1.34's release notes (or this thread here). |
| ||
| Hi, Ok, cool. I'm gonna do a 1.38 release soon so will include this. |
| ||
| @Mark: Will you include the IDE translations too? @Seb: Could you upload a compiled 1.37 IDE for win32? I want to check if the find bug is still present. Getting errors when trying to create my own: C:/BlitzMax/lib/libgcc.a(unwind-sjlj.o): undefined reference to `__mingwthr_key_dtor' C:/BlitzMax/lib/libgcc.a(gthr-win32.o): undefined reference to `__mingwthr_key_dtor' Build Error: Failed to link C:/BlitzMax/src/ide/maxide.exe |
| ||
| Wow, this thread got way off-topic for me. :) At any rate, I have just gotten the source for 1.38 MaxIDE and compiled for use, but the problem remains. I can also say one other thing: occasionally, instead of returning a random integer, and only if I did another Find at some point before, I actually get the previous Find's results. For instance if I hit Ctrl-F and look for "blue" and get a result, I might hit Ctrl-F again and look for "yellow", but it acts like I searched for "blue" again and gives me those results once more. So, it's as if there's a queue list of some sort and sometimes it is grabbing the last one. Maybe the integer returned sometimes is really just a failure when it incorrectly tries to find the previous Find request info. That's about all I can offer further on it. Happens on both my laptop and desktop, both well-tuned running Win7 x64, and now Bmax 1.38. My main project source is over 500k, if that matters to you. It's still very annoying to move around my code. Thanks for any help you can give. |
| ||
| Hi, Ha! It's back! Have you update BMX/MaxGUI to the latest versions too? |
| ||
| I'm convinced now, the only possible explanation is that Max is screwing up the stack in some convoluted circumstance. And this "Find" bug happens to reproduce it. The Debug log Grisu posted still has me scratching my head. How can a function be passed a string as a parameter, and then magically confuse that with a different string when it's actually executed? See post #12 in this thread. |
| ||
| Hi, > Again, only happens with MaxGUI.Win32MaxGUIEx. No reported incidents with MaxGUI.CocoaMaxGUI or MaxGUI.FLTKMaxGUI (either on Windows or Linux). :S Has this definitely, absolutely been confirmed? (and this has STILL never happened to me!) |
| ||
| Has this definitely, absolutely been confirmed? (and this has STILL never happened to me!) Everything I know about this issue is in this thread. As I say, I don't recall there ever being anyone reporting this issue on Mac or Linux, and Grisu tested an FLTK Windows build of MaxIDE and he said, despite trying, he could not reproduce the bug using the FLTK build at all. (Same here! I've run BlitzMax on several of my home computers, and have never come across this problem.) |
| ||
| Hi, Is there anything I can do to increase the chances of this happening?!? |
| ||
I get this too. This seems to be doing it for me -- type/paste into an empty tab:Print "Hello world" Hit Ctrl-F and search for hello. Then hit Ctrl-F again -- here, it pops up with (including quotes) "Hello world". It seems to be something to do with it automatically taking whatever token (keyword, item in quotes, etc) the cursor is currently in or nearest to. Placing the cursor on the line before Print brings up Print on hitting Ctrl-F. Placing it on any line after this, I get world (no quotes). None of this stuff is being manually pasted in, or on the clipboard. |
| ||
| Hit Ctrl-F and search for hello. Then hit Ctrl-F again -- here, it pops up with (including quotes) "Hello world". It seems to be something to do with it automatically taking whatever token (keyword, item in quotes, etc) the cursor is currently in or nearest to. Placing the cursor on the line before Print brings up Print on hitting Ctrl-F. Placing it on any line after this, I get world (no quotes). None of this stuff is being manually pasted in, or on the clipboard. The behaviour you are describing has actually been specifically coded for in MaxIDE, so I left it as it was when I started tweaking bits here and there. I found it a bit curious and unexpected but I figured Skid/Mark must have put it there for a reason. See the WordAtPos() call in TOpenCode.Find(). Unfortunately, I don't think this is related to the "random number" string bug peeps are reporting here. |
| ||
| Hi, > Hit Ctrl-F and search for hello. This is apparently by design! But, looking at Josh's vid above, the bug does only seem to happen when the find requester is 'preloaded' with something and the find term is typed in over this. Probably a coincidence, but the SetText code in TextField also looks a bit dodgy to me - if the replacement text is longer than the selection, it will attempt to set a selection beyond the end of the new text. Windows will almost certainly catch this and prevent anything bad happening, but hey, I'm clutching at straws here! |
| ||
| I have to agree... when I noticed a Ctrl-F returning responses from previous Find attempts, the cursor location was irrelevant. Now I'll have to pay attention as to whether it is affected by being "preloaded" or not. So far I have never had this issue in the Linux GUI. I have updated all my sources and modules. |
| ||
| Hi, > I have to agree... when I noticed a Ctrl-F returning responses from previous Find attempts, the cursor location was irrelevant. Are you sure this isn't just to do with the find requester preloading whatever happens to be 'near' the cursor (which is often a previous find result)? I personally find it a little confusing at times - the contents of the find requester can seem quite random when you hit Ctrl-F! Of course, as soon as you type in something to replace the old find string, it should stay there (well, at least until the next time you hit Ctrl-F). Have you definitely had the 'weird integer' problem with the latest builds? Or just previous find results? |
| ||
| Yes, and though I agree with you that it's very strange sometimes what the IDE "picks" to preload in the Find textbox, I don't see any correlation there at all in behavior. Everything looks like it will be searching for what I put in or what is preloaded; the only difference is that what it actually stops and highlights are the previous Find results. Or alternatively, the weird integer failure pops up, which does still happen and has always been more frequent than this previous-Find result. Both of these issues have happened since I started this thread; I just kept forgetting to mention the other odd bit of behavior (EDIT: oh wait, I did mention it in number 17 six months ago :) ) |
| ||
| Ok, I've just installed Windows 7 x64 and MaxIDE 'Find' looks completely borked. Not sure what is going wrong, at the moment, but will look into it over the summer. At least I can kinda reproduce a problem on this end, although I haven't ran in to the random number string thing yet. |
| ||
| Cool. I agree also that I haven't seen the random integer thing any longer after upgrading to the latest code. Now occasionally I get no result at all instead (the Find completes but nothing is highlighted), and I still constantly get old or odd results. I can also confirm that the same problem occurs when hitting the Find button as opposed to Ctrl-F. At any rate I'm glad others can reproduce it. Thanks for the help. |
| ||
| My problem with MaxIDE and Windows 7, 64-Bit. Basically ... CTRL-F, search for a string ... finds string no problem CTRL-F, search again for a different string ... you can enter the new string but it "finds" the last entered string and does it over and over every time, unless - you got to the top of the program listing and click once on the screen with the mouse. Then try again and it works. Very frustrating ! Doesn't do it on my Linux box or XP 32-Bit at work. JD |
| ||
| Me too. MaxIDE 1.38 + Windows 7 x64 I just opened a new project, added some numbers to the project, started to search for them. A few search attempts, and it gave me faulty results. Seems like it sometimes remembers the previous (not) found search string. And set it as the highlighted search string. Search string: hello result: could not find 'hello' Search string: test result: could not find 'hello' I also got this result: Search string: 1 Match/Text marked Search string: hello No errors , but the IDE marked 1 as the found search. |
| ||
| Hi, Holy crap - I think I've actually found this one! It's actually a reasonably major bug, but only affects x64 versions of Windows and apps that GCCollect inside Win32 callback functions such as WndProc, EnumWindows etc. Fix coming soon... |
| ||
| Yay! can't wait! I haven't bumped into a find bug in a while but when it was cropping up it was just death... I had to open stuff in a text editor to search, find the line number then go back to max... |
| ||
| YEAH... Hipp Hipp Hurray! |
   |