1. Find your way through the deepest dungeon in the 18th Mini Mapping Contest Poll.
    Dismiss Notice
  2. A brave new world lies beyond the seven seas. Join the 34th Modeling Contest today!
    Dismiss Notice
  3. Check out the Staff job openings thread.
    Dismiss Notice
Dismiss Notice
Hive 3 Remoosed BETA - NOW LIVE. Go check it out at BETA Hive Workshop! Post your feedback in this new forum BETA Feedback.
Dismiss Notice
60,000 passwords have been reset on July 8, 2019. If you cannot login, read this.

A new TESH Syntax Highlighter for Warcraft 3

Discussion in 'Warcraft Editing Tools' started by looking_for_help, Dec 28, 2013.

  1. Glowackos

    Glowackos

    Joined:
    Feb 28, 2011
    Messages:
    15
    Resources:
    0
    Resources:
    0
    1. Looks like the hex in styles.ini might be backwards.
      eg. 0xD8AB70 == rgb(216,171,112)
      but you're saving that rgb value as 0x70ABD8.

      It 's not an issue unless someone tries to edit the styles.ini manually, in which case they need to put in the hex values backwards.
    2. Also a minor nitpick re styles.ini, what's the reasoning for enforcing
      ```
      blah.backcolor=0x...
      blah.backcolor_index=1
      ```
      only to hide it with `blah.transparent=1`.
      Surely these could all just be unset by default, and then setting them would override the background colour?
    3. Worldedit hangs on closing if tesh has been started up during that session, sending me through two forcequite cycles before it finally gives up and goes away. (wc3 tft 1.28, cannot confirm if this is new, or if it affects 1.27b as well).
    Rest looks pretty sweet! :)
    More feedback to come later.
     
  2. looking_for_help

    looking_for_help

    Joined:
    Dec 12, 2012
    Messages:
    995
    Resources:
    5
    Spells:
    2
    JASS:
    3
    Resources:
    5
    Thanks for the feedback.

    Yes thats right. This is because COLORREF stores colors in BGR order.

    Maybe I will change that to store RGB, however I don't really see a reason why someone would modify the styles.ini manually.

    Actually there is a pretty massive amount of plausibility checks implemented in the option file parser to avoid that manual modifications of this file can lead to undesired effects/crashes. So, it is not neccessary to manually modify that file: every possible option can also be set from within the WE.

    Its not hidden, the color is actually used. There are several things to consider here, I have put quite some time in thinking this through before implementing this. Let me explain:

    Typically, when users change the backcolor of the whole editor (the background of the editor itself), it is expected that other styles also change their backcolor "automatically". I.e. that they behave as if transparent.

    For example, if I want to use a dark backcolor style, I usually just want to change the editor backcolor to black. I don't want to set the backcolor of all other styles manually to black as well, because thats redundant and tedious work. Therefore changing the editor backcolor should change other styles backcolors as well.

    However, what happens if for some styles, I actually want to have a different backcolor. Then I don't want that this information is lost/overwritten when changing the editor backcolor.

    There are basically two approaches to resolve this issue:

    1. Change only the backcolor of styles automatically, that had the same backcolor as the editor backcolor before the change was requested.
    2. Use a seperate flag to let the user configure which style should be "transparent". This is what is done in TESH 2.0.

    So, why was the second option chosen over the first? Because it gives the user more flexibility by avoiding undesirable effects: Imagine your editor backcolor is white, the backcolor of, say, native types is red. Now the user changes the editor backcolor to red. After that, the user changes the editor backcolor to green. If method 1.) was used, the algorithm would have no way to detect that native type backcolor should actually stay red, regardless of the editor backcolor.

    With option 2.) this is easily possible. It gives better control of style handling to the user. Therefore, this option was chosen for TESH 2.0.

    Why I write "transparent" in double quotes?

    Because the backcolor of the styles are not really transparent. Behind the scenes, if set to transparent, they look up the editor backcolor and just use this one.


    Yes, I have already identified (and fixed) that issue, will release a patch for this soon.

    Thanks, looking forward for that.
     
    Last edited: Apr 14, 2017
  3. Glowackos

    Glowackos

    Joined:
    Feb 28, 2011
    Messages:
    15
    Resources:
    0
    Resources:
    0
    Hehe, well i tried to translate my old config into your format, and felt it'd be quicker to just edit the styles.ini directly. :)
    I got it all to work, cept my colours turned out inverted. XD Trust Microsoft to make things weird. I'd suggest fixing this, though it's not huge priority. It just causes unnecessary confusion.
    In this vein, it would be sweet if there was a button in the WE TESH style editor section to reload from the styles.ini (i had to restart wc3 each time lol). Using the interface is a bit slow, esp since it doesn't let you feed in hex directly.

    Sure, but couldn't these just be left unset? ie if `text.backcolor` doesn't exist in the styles.ini file, use editor_background.backcolor in its stead. If it is set, use it. Then there is no issue with unintentionally overriding settings, as when the user selects a different global backcolour, only the editor_background.backcolor value changes in styles.ini. Everything else simply defaults to this backcolour if nothing else is set. If they want a different backcolour for something, eg `selection.backcolor`, then when they set this, `selection.backcolor` is explicitly added to styles.ini.
    The old tesh used `backcolour=default` for these cases, but even that was superfluous imo. Just not including it in the file is enough. Then you might not even need the "transparent" flag.
     
  4. MindWorX

    MindWorX

    Joined:
    Aug 3, 2004
    Messages:
    690
    Resources:
    5
    Tools:
    1
    Tutorials:
    4
    Resources:
    5
    Did you change how your injection works in the new version? I just tried out the current version with the JNGP replacement and it crashes the editor on startup. This doesn't happen with the old TESH and your previous version.
     
  5. looking_for_help

    looking_for_help

    Joined:
    Dec 12, 2012
    Messages:
    995
    Resources:
    5
    Spells:
    2
    JASS:
    3
    Resources:
    5
    Ok, that makes sense.

    Will be added in the next patch.

    So you only meant why it is stored in the styles.ini like that, right?

    Well, it could also be implemented like you explained. However, I don't really see an advantage over the way how it is done at the moment. I prefer to have everything explicitly stated in the file, because the structure of the file is then always the same and there are no implicit settings obscuring any options from the user. Also it avoids inconsistent states like setting transparent to 0 manually in the file, while not specifying a backcolor.

    Of course that could again be checked when the file is read, but I prefer that if users want to modify the file manually, they at least have all options to modify there directly - without adding or deleting any lines, but just changing values.

    However, I will probably display the transparent flag differently in the file... maybe just like text.backcolor=transparent instead of specifying the color itself.

    Yes, there are some differences... which JNGP replacement did you use? Which OS are you using and do you get any error messages?
     
  6. MindWorX

    MindWorX

    Joined:
    Aug 3, 2004
    Messages:
    690
    Resources:
    5
    Tools:
    1
    Tutorials:
    4
    Resources:
    5
    I'm using my SharpCraft project which simply loads up your dll. I do have some of my own hooks into various functions like CreateWindowsEx and SetMenu. I also override the GWL_WNDPROC, but I do read out the old one and call it after my own logic.

    I'm on Windows 8.1, and there are no errors, just a crash.

    It might make sense if we work together a bit and make a SharpCraft specific version of your plugin, since JNGP will be discontinued.
     
  7. Glowackos

    Glowackos

    Joined:
    Feb 28, 2011
    Messages:
    15
    Resources:
    0
    Resources:
    0
    Awesome, thanks :)
    Sounds good!
    wat? JNGP2.0?
     
  8. looking_for_help

    looking_for_help

    Joined:
    Dec 12, 2012
    Messages:
    995
    Resources:
    5
    Spells:
    2
    JASS:
    3
    Resources:
    5
    Ok, I will take a look into this, thanks for the feedback.

    Well, I don't really want to have multiple versions around at the same time... at least if that can be avoided. I think having just one single version that works for everything is better and avoids confusions.


    Hm, did I miss something?
     
  9. MindWorX

    MindWorX

    Joined:
    Aug 3, 2004
    Messages:
    690
    Resources:
    5
    Tools:
    1
    Tutorials:
    4
    Resources:
    5
    Since JNGP is still stuck on version 1.21, it's breaking more and more, like GUI features crashing the editor and the recent MPQ changes that broke it as well. We have better alternatives that are updated and work with the most recent patches, so it's not worth the hassle to try and keep JNGP working.
     
  10. Kazeon

    Kazeon

    Joined:
    Oct 12, 2011
    Messages:
    3,299
    Resources:
    38
    Icons:
    2
    Tools:
    1
    Maps:
    7
    Spells:
    21
    Tutorials:
    3
    JASS:
    4
    Resources:
    38
    This sometimes crashes the WE when I open a trigger. But it's quite rare to happen, and it can happen to any trigger. Is it somewhat related to the patch 1.27b I'm using?
     
  11. KILLCIDE

    KILLCIDE

    Administrator

    Joined:
    Jul 22, 2015
    Messages:
    3,505
    Resources:
    20
    Models:
    2
    Icons:
    10
    Spells:
    7
    Tutorials:
    1
    Resources:
    20
  12. Kazeon

    Kazeon

    Joined:
    Oct 12, 2011
    Messages:
    3,299
    Resources:
    38
    Icons:
    2
    Tools:
    1
    Maps:
    7
    Spells:
    21
    Tutorials:
    3
    JASS:
    4
    Resources:
    38
    Looks like it's different. For me it never crashed when I save maps. Only happen when I open a trigger.
     
  13. DD_legionTN

    DD_legionTN

    Joined:
    Dec 19, 2012
    Messages:
    411
    Resources:
    0
    Resources:
    0
    Not sure if it is TESH related, but this is the first time I encountered run-time error while using WE with TESH 2.0. Here is the image :

    Run-time Error

    [​IMG]


    And another thing is, although not a big deal, WE tends to crash while I close it, and appear to have this error message before the crash message :

    Error

    [​IMG]
     
  14. looking_for_help

    looking_for_help

    Joined:
    Dec 12, 2012
    Messages:
    995
    Resources:
    5
    Spells:
    2
    JASS:
    3
    Resources:
    5
    Now fully WEX and Sharpcraft compatible. Also fixed quite some small bugs. Styles can now be reloaded at runtime. Tabs and spaces are now handled "as expected".

    Update to version 0.9.1
    • Fixed a crash when closing WE
    • Added compatibility with WEX and Sharpcraft
    • Fixed that sometimes, text window was displayed over GUI
    • Fixed short flickering of the editor when starting WE starts for the first time
    • Added the option to load style themes at runtime
    • Fixed that under some circumstances, function list text could be modified
    • Fixed tabs to spaces does not take into account effective tab length
    • Fixed spaces to tabs does not take into account effective tab length
    • Added the option to use spaces instead of tabs
    • Fixed loading special characters from template files causing wrong encoding
    • Fixed error on loading trigger editor name from file containing unicode characters
    • Added an exported function to the dll to set the search string for the TE window programmatically
    • Changed all predefined templates from using tabs to using spaces by default
    • Styles are now stored as RGB instead of BGR in the styles.ini file

    And attached an image of the new option dialog.

    Options

    [​IMG]


    Looking forward for feedback.
     
  15. psxlover

    psxlover

    Joined:
    Dec 30, 2010
    Messages:
    66
    Resources:
    0
    Resources:
    0
    0.9.1 can't open files (options/style) if it is located in a folder with non ASCII characters:

    [​IMG]

    If I move WEX in a folder without greek characters the options/style/function.db load correctly.
     
  16. psxlover

    psxlover

    Joined:
    Dec 30, 2010
    Messages:
    66
    Resources:
    0
    Resources:
    0
    I also noticed a strange issue with font rendering.
    I changed my font to Consolas, and noticed that even though the font is monospaced the space size was not the same as the character size. Changing the font size to 11 for consolas it renders as a proper monospaced font but any other size renders wrong.
    Trying with Courier New the font remains monospaced for any font size up to size 10. Any higher than that and the spacing is wrong.

    Also what does "Filter legacy TESH scroll/fold info"? Does it remove those two line left by the old TESH, or does it use them to restore the last editor state?
     
  17. looking_for_help

    looking_for_help

    Joined:
    Dec 12, 2012
    Messages:
    995
    Resources:
    5
    Spells:
    2
    JASS:
    3
    Resources:
    5
    Will be fixed in the next patch.

    Will take a look into this, thanks.

    It just removes the two lines if they exist (if unticked, the two lines are not removed).

    In theory this legacy trigger state info could be used by TESH 2.0 as well to restore the last editor state. However, it doesn't really make sense because both fold and scroll state are already stored internally in the new TESH. So whenever you switch to a new trigger and then move back, both the fold and scroll state will be restored without modifying the trigger script. This has the benefit that the dirty flag isn't raised for the TE.
     
  18. psxlover

    psxlover

    Joined:
    Dec 30, 2010
    Messages:
    66
    Resources:
    0
    Resources:
    0
  19. MindWorX

    MindWorX

    Joined:
    Aug 3, 2004
    Messages:
    690
    Resources:
    5
    Tools:
    1
    Tutorials:
    4
    Resources:
    5
    I've had a few reports from @Spellbound and @Kithio who have been experiencing crashes when coding. Spellbound tried switching back to old TESH and haven't been having any problems since. Problem is, it's a periodic/unreliable crash so it'll be hard to debug.
     
  20. psxlover

    psxlover

    Joined:
    Dec 30, 2010
    Messages:
    66
    Resources:
    0
    Resources:
    0
    I also had a crash the first time I used it. For me it happened when I opened another trigger, and hasn't happened since so I have no Idea how to reproduce it.