https://linen.dev logo
Join Discord
Powered by
# haxe-ui
  • b
    it might be worth thinking about a virtual cursor and a way to slow down tests... i know from working with functional tests for a project i work on, that often seeing what is going on in essential
  • l
    yeah tests running to fast for human eyes might be an issue, especially when writing tests. there is a lot of trial and error involved to figure out how to "find" a component and then look up what properties it has. and if things happen to fast to see, then you'll end up putting 
    Sys.sleep
    in your testcase to slow it down.
  • b
    actually, btw, i forgot to mention, Sys.sleep isnt a great idea in general
  • b
    i dunno if you just put it in the test project you send me
  • l
    I'll have to see how to implement it in a way that you can turn it on or off. same goes for virtual cursor, you might want to have it, especially during development (and maybe on screenshots).
  • b
    but it pauses the thread, so you dont really get the "up/down" events (in the sense that they arent really being processed as you think)
  • l
    you're right, the sleep in that last test case doesn't make sense. in my lib it works because everything runs in a separate thread
  • b
    ah, thats fair... makes sense
  • b
    arent you then pausing the socket thread though?
  • b
    timers and promises / futures certainly seem like probably a better way to go, but thats just from my (single threaded) tests - as you can see from the .hx above
  • l
    yes, but since executing a command from a test is a "synchronous" operation (the test side waits for a response before sending the next command) pausing the socket thread has had no noticeable side effects.
  • b
    hmmm, you are using my hxWebSockets right?
  • b
    do you have "async handlers" set?
  • b
    (i cant remember the property)
  • b
    but yeah, i guess, thinking about it, even if you didnt, it wouldnt make a difference, its not like you are expecting multiple clients?
  • l
    -D threaded_server
    and 
    -D threaded_handlers
  • b
    but yeah, realistically, this is just a server and (presumably) a single client... so threaded_handlers doesnt matter so much (though still cant hurt)
  • l
    no, it's meant to be 1:1 even though my test app opens the socket server and the app connects to it (because that also works for HTML5 projects), so technically there could be multiple clients connecting to the same testing app. but as far as I know utest doesn't support running parallel tests (and no other Haxe testing framework does either), so it would still be sequential test runs.
  • b
    gotcha, makes sense
  • b
    so the threading doesnt really matter that much as long as the server is in a different thread to the client (which threaded_server will do)
  • b
    and yeah, the sleeps wont affect the server, since you have threaded_handlers set, though, just an fyi, if you didnt you would be locking up the servers ability to accept new incoming connections everytime you did a sleep
  • l
    new connections only come into play in between test cases, when the app is relaunched / on page reload. maybe sleeps are not an ideal solution, but so far it works for what it's supposed to do and there is always the option to implement a better version in the future when requirements change or issues arise.
  • b
    cool - yeah, just highlighting as its one of the first things i noticed when i was playing around that the "down" and "up" were processed, basically and the same time because of the sleep (rather than a timer that would let events process in between)
  • b
    but it sounds like its less of an issue with something more real (like haxeium) since its a multithreaded env anyway
  • l
    I think I copied that part over from my lib code and didn't even think about it making no sense in that sample
  • b
    yeah, fair enough, i kinda figured that tbh, but then i though "ah, i bet hes using sleep in haxeium" without actually thinking that it was threaded anyway 🙂
  • h
    I'm getting internal errors when trying to use haxeui-hxwidgets
  • h
    Copy code
    C:\HaxeToolkit\haxe\lib\haxeui-hxwidgets/1,4,0/haxe/ui/backend/ScreenImpl.hx:36: characters 30-45 : Field removeComponent overrides parent class with different or incomplete type

C:\HaxeToolkit\haxe\lib\haxeui-core/1,3,0/haxe/ui/backend/ScreenBase.hx:73: characters 21-36 : ... Base field is defined here

C:\HaxeToolkit\haxe\lib\haxeui-hxwidgets/1,4,0/haxe/ui/backend/ScreenImpl.hx:36: characters 30-45 : ... Different number of function arguments

C:\HaxeToolkit\haxe\lib\haxeui-core/1,3,0/haxe/ui/core/Screen.hx:55: characters 30-45 : Field removeComponent overrides parent class with different or incomplete type

C:\HaxeToolkit\haxe\lib\haxeui-hxwidgets/1,4,0/haxe/ui/backend/ScreenImpl.hx:36: characters 30-45 : ... Base field is defined here

C:\HaxeToolkit\haxe\lib\haxeui-core/1,3,0/haxe/ui/core/Screen.hx:55: characters 30-45 : ... Different number of function arguments
  • h
    I'm not sure what's causing it, since this is an unaltered template
  • h
    uninstalled and reinstalled haxeui-core and it works now so whatever it was is my end
1...120912101211...1687Latest