Trying to override loadimage.
BlitzMax Forums/BlitzMax Beginners Area/Trying to override loadimage.
| ||
| Someone told me before that I could stick a . in front of a function name to get the global function when in a function of the same name inside a type. Another person mentioned another way to access the original function but I forgot that method and I now suspect the first method only worked for types but not for "global scope" functions like I have here. Does anyone know what I put in front of the function names instead of a . to fix this? It just calls itself recursively right now:
Function LoadImage:TImage(Url:Object, Flags%=-1)
Local Image:TImage
Image = .LoadImage(Url, Flags)
If Image = Null Then RuntimeError("The following image failed to load: " + String(Url) + ". Please reinstall the game.")
Return Image
End Function
Function LoadAnimImage:TImage(Url:Object, Cell_Width%, Cell_Height%, First_Cell%, Cell_Count%, Flags%=-1)
Local Image:TImage
Image = .LoadAnimImage(Url, Cell_Width, Cell_Height, First_Cell, Cell_Count, Flags)
If Image = Null Then RuntimeError("The following image failed to load: " + String(Url) + ". Please reinstall the game.")
Return Image
End Function
|
| ||
Brl.Max2D.LoadImage Brl.Max2D.LoadAnimImage ... etc. |
| ||
| Hm... RunTimeError isn't throwing up a dialog box unless I'm in debug mode. I set the graphics mode beforehand... What gives? Wow, and Assert completely fails to detect that the image wasn't loaded AT ALL! If Image = Null Then RuntimeError("The following image failed to load: " + String(Url) + "Please reinstall the game.")Succeeds, but only prints the error to the debuglog, unless in debug mode, in which case it brings up a dialog box as expected, or in the case of a release executable, where it does nothing but cause the application to exit. Assert Image, "The following image failed to load: " + String(Url) + "Please reinstall the game." Fails to stop the program normally. In debug mode, brings up a dialog box but application refuses to exit after it is dismissed and close program must be selected from start bar. |
| ||
| Assert only exists in debug (it would be a bad performance hit) If you want to have a safe handling of errors use throw and enclose loading in Try - Catch - endtry blocks. And I would suggest using Url.tostring() for print out ... its the correct way as URL might be and img / pixmap as well. |
| ||
I never use runtimeerror I just use Notify. Tho I did just try it like this:Function LoadImage:TImage(Url:Object, Flags%=-1)
Local Image:TImage
Image = Brl.Max2D.LoadImage(Url, Flags)
If Image = Null Then RuntimeError("The following image failed to load: " + String(Url) + ". Please reinstall the game.")
Return Image
End Function
Function LoadAnimImage:TImage(Url:Object, Cell_Width%, Cell_Height%, First_Cell%, Cell_Count%, Flags%=-1)
Local Image:TImage
Image = Brl.Max2D.LoadAnimImage(Url, Cell_Width, Cell_Height, First_Cell, Cell_Count, Flags)
If Image = Null Then RuntimeError("The following image failed to load: " + String(Url) + ". Please reinstall the game.")
Return Image
End Function
LoadImage("blah")And it appers that it shows the error in the console when not in debug mode. I guess runtime error is for develops only. edit: what Dreamora said about try..catch |
| ||
| "Assert only exists in debug (it would be a bad performance hit)" How in the hell is "throwing a runtime error if the condition is false" going to cause a performance hit? All it is doing is the same thing as my IF statement! According to the help file this is what it should be doing: Function Assert(Condition%, Error$) If Condition = False Then RuntimeError(Error$) End Function |
| ||
No offense, but Throw, Catch and Try are utter crap.Rem Throw generates a BlitzMax exception. End Rem Try repeat a:+1 print a if a>20 throw "chunks" forever Catch a$ print "caught exception "+a$ EndTry That isn't easy to parse at ALL. What on earth is wrong with:
repeat
a:+1
print a
if a>20
print "caught exception chunks"
exit
endif
forever
I could see maybe MAYBE if you had a whole mess of conditions that could fail in a block of code and you wanted them to all throw up different errors, but how often does that happen? I can't think of a single time I've ever had such a situation crop up. |
| ||
| Ph and Diablo, thanks for the Notify suggestion. Notify + End works. I guess I'll just override RuntimeError with notify and end to work around this stupid bug. |
| ||
| "And I would suggest using Url.tostring() for print out ... its the correct way as URL might be and img / pixmap as well. " What's the difference? Either way you can't convert an image or a pixmap to a string. Won't both methods just result in a null string if it is not a string? |
| ||
| Try Catch and Throw are pretty industry standard for OO languages. Delphi has Try Except and Raise. |
| ||
| .Net has them also |
| ||
| Sswift: Problem is you don't understand the use of try - catch. You try catch it directly in the function here ... but try catchs power lays far far FAR above that because you can try catch in the main loop and if one of the functions called within a function called within a function throws something your mainloop try will still catch the error, so you can do ALL error handling in 1 single spot!! Thus I always use the throw approach instead of 1 million local error handling approaches that will end inconsistent and user annoying (like returning null/0/"" as BRL products do it or did it until recently) ... thats acceptable for unexperienced users at best. |
| ||
| You try catch it directly in the function here ... but try catchs power lays far far FAR above that because you can try catch in the main loop and if one of the functions called within a function called within a function throws something your mainloop try will still catch the error, so you can do ALL error handling in 1 single spot!! I still don't see the benefit. How is this better than having a custom RuntimeError function? In your example, wherever you have an error, you call Throw, and pass it a string, which causes a goto-like jump out of wherever you are into your catch loop. But I can do the exact same thing with a function, and it doesn't require and extra typing. 1 million local error handling approaches that will end inconsistent If all my errors call a custom "Throw" or "RuntimeError" function that displays the error and exits the program, that isn't inconsistent. And "1 million" implies I have to do more typing than your try catch approach, which is simply not true. Show me one single case where Try Catch works better or simplifies things more than this RuntimeError function: Function RuntimeError(Error$) EndGraphics Notify(Error$, True) End End Function It doesn't matter if I call that from the main loop, or three functions down in a recursive loop. It will still exit the program and display the error which is totally consistent. |
| ||
| The problem is that you throw strings ... Thats not really that usefull beside giving an error directly to the user. If you want the users to be usable for users of your system, make exception classes (extending the base exception class of BM) and throw instances of those. That way handling is far easier and more "advanced" than "there is an error like blubb - thats it" |
   |