https://linen.dev logo
Join Discord
Powered by
# haxe-ui
  • c
    i can just pick one of those at random that i havent changed any code in and they will produce mouse warnings.
  • c
    i never turn my warnings off... i like to see whats going on.
  • c
    Maybe there was a slight change in the Haxe update that is going to require updates to the mouse events in these backends using haxe. I'll try to pay more attention today. About to work on getting Ace going again. See what kind of warnings I see popping up here and there that are mouse related.
  • c
    I also found some Ace externs it seems a russian haxer created. May fool around with those later. They are going to require some slight editing to use.
  • c
    this one..... i did...... haxelib run haxeui-core create html5 for a quick template.......
  • c
    so, definately not some code i managed to screw up lol
  • l
    Those warnings about things that might be used before being initialized are not wrong, if you look at the code in question, there is no assignment before they are being used. And if you look closely, there is no such warning for 
    __onMouseMove
    , because that one has a 
    = null
    assignment, the others don't. The places that Haxe 4.1 now complains about were equally (potentially) problematic in Haxe 4 or Haxe 3, but they didn't tell you about it.
  • c
    ahhhh ok, thanks Alex..... so Haxe 4.1 is more informative on the issues now..... i likes the sound of that.
  • c
    that code in the last screenshot is not the code i ran.... i'm always doing multiple things... i just happen to be checking that code out while working on something else to plan ahead with ideas of what to possibly try.
  • c
    makes me want to tinker around with those mouseevents..... "damnit shaun stop, focus..... stay focused................. oooooohh but the urge....... oooh loook, a squirrel." my daily routine lol
  • c
    wysiswyg drag n drop builder for haxeui..... hmmmm....... i think i'll attempt it when i get this other figured out.
  • b
    they are also fixed in git version of haxeui-core
  • b
    you are on 1.025
  • b
    the __js__ one is interesting
  • b
    this is the line:
  • b
    Copy code
    haxe
            if (s == untyped __js__("undefined")) {
                s = null;
            }
  • b
    and i have NO idea why it needs that js part... i would assume its there for a reason though
  • b
    even this seems very specific:
  • b
    Copy code
    haxe
                var error:String = "Http Error #" + request.status;
                switch(s) {
                    case 12029:
                        error = "Failed to connect to host";
                    case 12007:    
                        error = "Unknown host";
                    default:
                }
  • b
    Copy code
    haxe
#if js // cant use haxe.Http because we need responseType
  • b
    that explains it somewhat i guess
  • b
    Copy code
    haxe
#elseif cs // hxcs bytes are wrong in haxe.Http
  • b
    😄
  • c
    well, that may explain it
  • b
    be interesting to see if all that #ifdef stuff isnt needed now, but since haxe 3 still needs to be supported i guess im stuck with it for now
  • b
    shouldnt be hard to pull binary data from http, but sometimes the stdlib in haxe leaves a little to be desired for
  • b
    i guess the hxcs target is basically unsupported too now (maybe?), its used for haxeui-winforms
  • b
    still, its nice in haxe that even if the stdlib "misbehaves" you can just jump into target specifics, so theres always something you can do to work around it
  • c
    true, always nice to have a little backup so to speak
  • b
    this is the code that i guess was supposed to "just work", but didnt, so thats why there are js and cs versions that use XMLHttpRequest and cs.system.net.WebRequest
1...231232233...1687Latest