Jump to content
Sign in to follow this  
sbsmac

Squint - the sqf editor and error-checker

Recommended Posts

I will try and troubleshoot, but another issue is that Ctrl - Z or undo at the top does not work for me either.

Share this post


Link to post
Share on other sites

Thanks - I've just fixed the ctrl-z issue in 1.0.0.93 (forgot to wire up the menu action because I'm so used to using ALT-BKSPC :) )

Share this post


Link to post
Share on other sites

Good news first - I know what is causing the hang -more annoying MS UI threading limitations.

Bad news - my cunning plan to use a RichTextBox in a background thread to do highlighting now looks like it will not work and I'm contemplating having to write a simple RTF encoder.

More later....

Share this post


Link to post
Share on other sites

Not sure if I am the only one experiencing this. However, I found editing config files in pbo very buggy. Sometimes when deleting some text it seems to be gone. The line numbers decrease. Then 2s later when scrolling the text is back.

Sometimes (often) when writing/editing more about 2 lines it seems to hiddenly revert back to the text before.

Share this post


Link to post
Share on other sites

Strange - I just tried this with a randomly selected pbo (l39.pbo) and it all seemed fine. Is the config file you are editing particularly large? I'm just finishing off the fix for the hang that Cobra reported which should in any case make the rendering a bit smoother and will see again if I can reproduce the problems you're seeing tomorrow. In the meantime, any extra information you can figure out would be helpful.

Share this post


Link to post
Share on other sites

Well first I wanted to delete 3000 lines because I was making some "on-top" changes (instead of writing from an empty file, I just wanted to remove irrelevant stuff from the config I was adding some changes to) to some configs. The lines just reappeared. I finally got a small 60 line config going, however as I was typing random text that I wrote got corrupted. I was writing "class" and it turned out to be "cladd". No i'm pretty sure I didn't hit the wrong key cause It was "ss" on the screen for a short while before being replaced. Sometimes part of the next line would be deleted and strange things.

While this is user error, you may want to catch the exception that occurs when you try to save the pbo you have opened in squint when arma is using it.

Share this post


Link to post
Share on other sites

I suspect everyone is too busy with BAF to care too much about this but....

1.0.0.94

*Bug #13297: Squint could hang when idle

*Bug #13299: Allow background colour and font of file-list and error window to be customised

*Feature #13205: Customisation of appearance

New dialog... appearance.PNG

You can also now change the font and background colour of the error-list and file-list

Share this post


Link to post
Share on other sites

that's great!

Thanks.

(and now back to BAF, :shoot::cancan: thiiihihihi)

Share this post


Link to post
Share on other sites

I've just added Import and Export buttons to the colour/font selection dialog. This will allow you to export your colour settings to an ".sxml" file.

If you come up with any colour schemes you are particularly proud of, please export them and post them here (the files are just small text files) and I will then start a library of 'themes' on the squint webpage.

Share this post


Link to post
Share on other sites

Despite 1.54 and BAF, still paying a lot of attention to Squint and loving it. Some good stuff coming out soon - made even better thanks to this tool.

Share this post


Link to post
Share on other sites

Thx - look forward to seeing it :)

<cough> Still hoping for some nice colour-schemes from people who thought they could do better than my black background :p

---------- Post added at 09:46 AM ---------- Previous post was at 08:26 AM ----------

I thought it was worth summarising the changes since squint's 'official' release last week.. Here's a copy of the project update on the squint page. Thanks again to all those who have offered feedback and suggested changes (and especlially to those whose quotes I have misappropriated!)

Squint went public just over a week ago and the feedback has been extremely pleasing...

"Flippin awesome tool. fixed a bunch of errors right on loading."

"Awesome tool thanks for sharing, already found some errors in a couple of scripts that I didnt even notice."

"Squint is a major help in finding errors - it found quite a few I must say I was shocked it was able to find (nice tracing through files)"

"This is amazing stuff! The best scripthelper created over the last 10 years. Love it!"

"Sorry SQF plugin for N++. It's just that I've met someone else. Someone who really get's me."

But no release is perfect and there have been a lot of great suggestions on how to improve squint. Based on those I've been working hard to add the following features....

* Support for the following file-extenstions: *.ext;*.sqm;*.cpp;*.hpp;*.rvmat;*.bin;*.cfg;*.pbl

* Line-numbers have been added to the code-window.

* Search and replace have been added

* An 'undo' feature has been implemented

* A basic auto-indent has been implemented; you can auto-indent code as you go along or select a region and hit TAB to auto-indent.

* Auto-complete/intellisense has been implemented. When enabled, squint will monitor your typing and offer you a choice of possible completions in a pop-up dialog box. This really saves a lot of time and effort for those long BIS_fnc_.. names! Auto-complete can also offer you completion for local variable names that are in scope and can help you avoid 'bracket-fatigue' by offering completions for common control constructs, eg "for [{},{},{}] do {};" as a completion of "for".

* The colour scheme is more flexible than before. You can change the background colour and font used by the file-list and error-list and you get an immediate preview of your colour-changes for the code-window.

* You can import and export colour 'themes'; I hope to host some user-made themes on the squint website over the next week - please contact me via the BIS forums if you have a colour-scheme you'd like to share.

* BIS & ACE function names have been added to the dictionary as 'known' global variables.

* An external helper app allows shell-integration. Just right click on a file to open it in squint !

* Support for binarised files is now implemented. You can edit the contents of config.bin or any other binarised file, even those already inside pbo's.

* The error-detection phase is now much faster for large multi-file projects.

* The code-window now has much less flicker when jumping around within a file.

* As well as the new features, a significant number of bugs have been fixed including one that could cause squint to hang while idle.

Thanks to all who have provided feedback so far - please keep it coming to help me improve the tool.

To learn more about the new features, see these two links

* Shell integration

* Tips & Tricks

As always, existing users should find that they are automatically updated to the latest version which is currently 1.0.0.95. If squint is not updating, you can force an update by re-running the setup file.

Edited by sbsmac

Share this post


Link to post
Share on other sites
"Support for binarised files now implemented" - Very nice. Great work .

Actually a quick clarification on that... atm it's only for viewing. If you try to save a modified binarised file you'll get a dialog saying you can't. I'm very close to getting this working but it'll take a few days and there don't seem to be a lot of people jumping up and down for this so other things will likely take priority.

Share this post


Link to post
Share on other sites

Looks really great but I must be dumb... I have installed Squint, and when I want to open a .sqm or .sqf file I have only "Open Project" button, and the file to be open "must" be .sqt?? How do I open a file whatever its name, and not a project??

Share this post


Link to post
Share on other sites

The thing to realise is that you are always working within the scope of a project, even if it's just the default 'new project'. So to open sqf/ext/pbo etc files, just use the "File->Add To Project" menu or, much easier, just drag them across from the desktop into the file-list.

The last slide of the presentation on this page

shows this.

*Edit* More info here

Edited by sbsmac

Share this post


Link to post
Share on other sites

<cough> Still hoping for some nice colour-schemes from people who thought they could do better than my black background :p

Somehow I feel slightly addressed by this, :D

Ok, here are two of them:

  1. a warmish one:
    <Codeview>
    <FontName>
    Consolas
    </FontName>
    <FontSize>
    11
    </FontSize>
    <Background>
    Snow
    </Background>
    <Highlight>
    AliceBlue
    </Highlight>
    <Default>
    Black;Regular
    </Default>
    <Comment>
    LightSlateGray;Regular
    </Comment>
    <LocalVar>
    OrangeRed;Regular
    </LocalVar>
    <GlobalVar>
    Firebrick;Regular
    </GlobalVar>
    <Operator>
    Black;Regular
    </Operator>
    <String>
    Navy;Regular
    </String>
    <DeffedOut>
    LightSkyBlue;Strikeout
    </DeffedOut>
    <Macro>
    LightSeaGreen;Regular
    </Macro>
    <Other>
    White
    </Other>
    <OtherFontName>
    Consolas
    </OtherFontName>
    <OtherFontSize>
    9.25
    </OtherFontSize>
    </Codeview>
  2. and a frosty one:
    <Codeview>
    <FontName>
    Consolas
    </FontName>
    <FontSize>
    11
    </FontSize>
    <Background>
    Snow
    </Background>
    <Highlight>
    AliceBlue
    </Highlight>
    <Default>
    Black;Regular
    </Default>
    <Comment>
    LightSlateGray;Regular
    </Comment>
    <LocalVar>
    DarkMagenta;Regular
    </LocalVar>
    <GlobalVar>
    Navy;Regular
    </GlobalVar>
    <Operator>
    Black;Regular
    </Operator>
    <String>
    DarkCyan;Regular
    </String>
    <DeffedOut>
    DarkSlateGray;Strikeout
    </DeffedOut>
    <Macro>
    DarkSlateGray;Regular
    </Macro>
    <Other>
    White
    </Other>
    <OtherFontName>
    Consolas
    </OtherFontName>
    <OtherFontSize>
    9.25
    </OtherFontSize>
    </Codeview>

Though I'm not really happy with them either (I'm using the latter).

For one, I'm absolutely no fan of your color-dropdown-boxes with color-names. Haven't you access to a regular color-picker? Using a list of name-colors is probably never a good idea (it wasn't even a good idea for things like "websafe colors" back in the other century)..

I mean, I have a name for the main colors, but that's were it ends. What is Salamon? A color? Really? Firebrick? What? CadetBlue or DodgerBlue? What's the difference? My argument is: I don't know these color-names and never will, thus this dropdown-list is barely useable. I know blue and red and yellow and green, but that's it. :D

The problem is also the order of the colors. Ordering them alphabetically by color-names is a bad idea. The natural (and thus useable) order of colors is the rainbow/color spectrum. Doesn't .net come with it's default color-picker?

Second, I don't think it's a good idea to show the font's in the font dropdown-menu. It makes it slow and hard to use. This is no photoshop, so I think we don't need a preview of fonts to choose one. (also I got an error browsing through my fonts, probably because some font was in an unuseable format.. so thats another reason to not do this and show the available fonts in a regular font)

Third, I'm not sure why, but somehow I feel it's all too colorful. Maybe that's the result of my code beeing written in an easy script language. Or maybe it's simply still a bit unfamiliar (in comparison to other editors/languages I use). But what strikes me most is that I really need to set the operators color to regular black, for if I don't, nothing is in regular text color anymore, which renders this exercise a bit useless (if everything is in color/important, then nothing is).

I think you need to further divide the "operators":

  • core syntax, control structures and the like (if, then, switch, etc.. but also all brackets/paranthesis); syntax
  • core/predefined commands; functions/commands
  • atomic values such as boolean or player (ok, you may argue this is a command, and probably you'd win the argument, hehe), which are currently also colored in the operators color; atomic

^^ Splitting this up a bit would for sure help to prevent everything from becoming a fancy color.

And also numbers should have their own color (like in most editors out there)

But otherwise I'm happy with the new options we've got.

Thanks and keep it up! ;)

Share this post


Link to post
Share on other sites

I have no idea why you would think I was referring to you Mr. Black :whistle:

Thank you though - very much appreciated and I have to admit I do rather like 'frosty'

Though I'm not really happy with them either (I'm using the latter).

Well, I've made them available here for those who want to try them - hope you don't mind my post-modernist art critique blurbs ;)

For one, I'm absolutely no fan of your color-dropdown-boxes with color-names. Haven't you access to a regular color-picker? Using a list of name-colors is probably never a good idea

Ah I see, you were just softening me up with the gift of the colour-schemes before moving in for the kill :p Let me explain the thinking and I'd be interested in other people's thoughts...

First, there is no 'standard' colour chooser in .Net apart from a full-on dialog which I thought was complete overkill (and I hated having to click 'change', pick the colour, click 'OK' again etc). So the drop-down style seems like a better option. But then you have to decide what to put in the drop-down list.. colour names, the colours themselves, or some combination? I agree the colour names aren't meaningful on their own. So I started by using the colours (like the original dialog). Then I decided it would be more meaningful to display some text in the desired colour on the chosen background colour so as to best indicate what the end-result would look like. The text is arbitrary but might as well be the colour-name rather than "sample text".

The ordering is as-they-are-sorted in the windows Color enum. I agree that 'rainbow' ordering would be better if someone can point me to a good (and simple to implement) RGB ordering algorithm.

I don't think it's a good idea to show the font's in the font dropdown-menu. It makes it slow and hard to use

The slowness is probably because there is some very inefficient redrawing of that dialog whenever anything changes (won't bore you with the details). Personally I like having the fonts displayed because I hate the traditional font-pickers where you have to keep clicking on a font to find out what it's going to look like.

also I got an error browsing through my fonts, probably because some font was in an unuseable format

If you can reproduce this, can you post the exception details here ?

Third, I'm not sure why, but somehow I feel it's all too colorful. Maybe that's the result of my code beeing written in an easy script language. Or maybe it's simply still a bit unfamiliar (in comparison to other editors/languages I use). But what strikes me most is that I really need to set the operators color to regular black, for if I don't, nothing is in regular text color anymore, which renders this exercise a bit useless (if everything is in color/important, then nothing is).

Yes actually I agree very much with this. It's probably because I have the colour-sense of a 5-year-old and the graphic-design skills of a chimp which is why, all joking aside, I'm very grateful to people who are willing to put together colour-schemes that look a bit more 'professional'. (My very first colour-scheme which I might yet publish as 'fisher-price' used comic-sans in large font and very bright colours and reminded me of something my children used to play with...)

magneticboard2.jpg&w=228&h=200&ow=350&oh=200

* core syntax, control structures and the like (if, then, switch, etc.. but also all brackets/paranthesis); syntax

* core/predefined commands; functions/commands

* atomic values such as boolean or player (ok, you may argue this is a command, and probably you'd win the argument, hehe), which are currently also colored in the operators color; atomic

Some of these would be easier than others; detecting whether an operator is 'atomic' (ie has no operands) is quite straightforard for the renderer. OTOH, brackets are just thrown into the general 'separator' category along with semi-colons and anything else and are currently rendered in the 'Default colour.

But otherwise I'm happy with the new options we've got.

Thanks and keep it up!

Thanks and even if I don't always agree, it's useful to have the feedback :)

---------- Post added at 03:23 PM ---------- Previous post was at 03:03 PM ----------

I've just had someone else report the font-choosing exception. Can anyone provide more details since I can't reproduce this here ?

http://dev-heaven.net/issues/13322

Share this post


Link to post
Share on other sites
...hope you don't mind my post-modernist art critique blurbs

Haha, certainly not. :D

Ah I see, you were just softening me up with the gift of the colour-schemes before moving in for the kill

:D:D:D

But really, you need a color picker and the default os color picker dialogue would be totally fine. You want good color schemes? Give us a color picker. For instance I'd like to have the same color for global and private variables, but with different saturation for example to get only a subtile difference... With your color-names list I'm totally screwed.

...and I hated having to click 'change', pick the colour, click 'OK' again etc

I'm sorry, but you won't play around with that dialogue anymore once it's setup. So this really does not need to be fast/quick workflow wise.. and even if, I'd argue that a color picker is still faster, because it's reliable. A color picker is easy to use and very precise, your colornames-list is absolutely not.

Personally I like having the fonts displayed because I hate the traditional font-pickers where you have to keep clicking on a font to find out what it's going to look like.

Uhm, even in photoshop(!) the font-selector drop-down is all rendered in a default font - for good reasons. If you don't know your fonts, I suggest you use a font-browser software or something. Squint should not do this too. It's not a font-browser and tools should not try to do too many things, but a few things really good. At least that's the software philosophy I agree with.

If you can reproduce this, can you post the exception details here ?

Posted them in your bug tracker. And yes, it's quite easy to reproduce, though I really can't tell what font causes the problem. All I have to do is scrolling through the font-list and at some point a font probably can't get rendered and then ... see, that's a problem font-browser software needs to deal with. You definitely shouldn't worry about that for squint.

Can anyone provide more details since I can't reproduce this here ?

http://dev-heaven.net/issues/13322

Done.

Share this post


Link to post
Share on other sites

Thanks for the exception details. Actually the issue was that one of the fonts in the list did not support 'Regular' style so whilst I could have deferred the exception for a bit by not rendering it in the selection box, it would still have caused a an exception if selected.

Anyway (hopefully) fixed now and I'll look at the colour stuff later.

Share this post


Link to post
Share on other sites
Anyway (hopefully) fixed now...

Ha, that was fast and indeed it is fixed now. At least I can't bring up that exception again. Though it's still a bit slow due to the rendering of all these fonts, but I can live with this now, I guess. :D

Share this post


Link to post
Share on other sites
The thing to realise is that you are always working within the scope of a project, even if it's just the default 'new project'. So to open sqf/ext/pbo etc files, just use the "File->Add To Project" menu or, much easier, just drag them across from the desktop into the file-list.

The last slide of the presentation on this page

shows this.

*Edit* More info here

Hello Sbsmac I found out finally how to open "as a project", but not working on projects, I've been left in the dark as to how to open a file on the fly; as would say Captain Obvious users of Windows are "trained" to find open,close file(s) buttons and not system project; it was new to me as a genuine no coder entity :D, thus why not adding a menu to quick open any file you check, because I tend to use files (opening for reference,checks,editing) from different missions, there's always a sqf you need when making a mission, and often they would be located in different folders from different missions. Why not adding my remarks in the FAQ?

Then questions come to mind as this one, tried Squint with BIS official missions and Squint found errors, even if the mission works fine, so my question is does Squint overkill in terms of errors?

Share this post


Link to post
Share on other sites

Right then ruebe, the colour-choosers in the editor settings page now have a little button labelled '...' which can be used to bring up the standard colour dialog so I expect to see some 'perfect' colour schemes from you now :p

Why not adding my remarks in the FAQ?

Good suggestion - will do. *Edit* Added here

Then questions come to mind as this one, tried Squint with BIS official missions and Squint found errors, even if the mission works fine, so my question is does Squint overkill in terms of errors?

Interesting point. Detecting errors in software is a 'hard problem'. As I'm sure you are aware, a mission that runs perfectly under some circumstances will sometimes have errors if you play it differently. Squint takes the approach of warning you about 'unsafe' code but just because it flags a warning doesn't mean that the code or mission is guaranteed to fail.

It's a bit like me coming to your house and pointing out that you storing petrol in empty milk bottles in the cupboard-under-the-stairs is not 'safe'. You might respond that you always keep the cupboard door locked, don't ever allow anyone who smokes into the building, and know what you are doing (and in any case, it's none of my damn business!) but when your house burns down the insurance company will probably say you were pretty daft to ignore my warnings ! :)

For example, a lot of the BIS mission scripts have code that looks a bit like this..

player sidechat format ["blha blha %1",_sentenceId] ;

where _sentenceId is a variable that is not defined in the script but which is assumed to exist by the author of the mission. It's very likely that BIS have written their missions in such a way that _sentenceId always will exist but squint flags a warning anyway. Why ? Well, one day, someone might forget that they need to define _sentenceId before calling the script. Thus squint is often warning you of potential errors rather than actual ones.

(Personally I think that the way the BIS missions call scripts is not terribly good coding and they should pass more stuff in as parameters but since we're not writing code for the space-shuttle here perhaps I'm overly picky!)

Note the difference between errors and warnings - denoted by 'E' and 'W' in the error-list. Errors are almost always definite syntax errors which you do need to fix whereas warnings are just indications of potentially unsafe code. (Interestingly, there are several real errors which I've found in the BIS missions using squint - just need to get around to reporting these.)

So coming back to your original question...

is squint overkill in terms of errors?

No. You can certain choose to ignore the warnings and often (as with my example about the petrol in your house) you can get away with it for a long time. However a warning is at least something you should look at and ask yourself whether you really intended to write the code that way. :)

Edited by sbsmac

Share this post


Link to post
Share on other sites
Right then ruebe, the colour-choosers in the editor settings page now have a little button labelled '...' which can be used to bring up the standard colour dialog so I expect to see some 'perfect' colour schemes from you now :p

Good suggestion - will do.

Interesting point. Detecting errors in software is a 'hard problem'. As I'm sure you are aware, a mission that runs perfectly under some circumstances will sometimes have errors if you play it differently. Squint takes the approach of warning you about 'unsafe' code but just because it flags a warning doesn't mean that the code or mission is guaranteed to fail.

It's a bit like me coming to your house and pointing out that you storing petrol in empty milk bottles in the cupboard-under-the-stairs is not 'safe'. You might respond that you always keep the cupboard door locked, don't ever allow anyone who smokes into the building, and know what you are doing (and in any case, it's none of my damn business!) but when your house burns down the insurance company will probably say you were pretty daft to ignore my warnings ! :)

For example, a lot of the BIS mission scripts have code that looks a bit like this..

where _sentenceId is a variable that is not defined in the script but which is assumed to exist by the author of the mission. It's very likely that BIS have written their missions in such a way that _sentenceId always will exist but squint flags a warning anyway. Why ? Well, one day, someone might forget that they need to define _sentenceId before calling the script. Thus squint is often warning you of potential errors rather than actual ones.

(Personally I think that the way the BIS missions call scripts is not terribly good coding and they should pass more stuff in as parameters but since we're not writing code for the space-shuttle here perhaps I'm overly picky!)

Note the difference between errors and warnings - denoted by 'E' and 'W' in the error-list. Errors are almost always definite syntax errors whereas warnings are just indications of potentially unsafe code.

So coming back to your original question...

No. You can certain choose to ignore the warnings and often (as with my example about the petrol in your house) you can get away with it for a long time. However a warning is at least something you should look at and ask yourself whether you really intended to write the code that way. :)

Your prog is amazing really, and you are not over picky I like fine tuning too like I do on my motorcyle, back on Squint I have simplified a sqf and it works great, even if I don't grab the code lingo, I'm really interested into it. EG :

Before :

_sideHQ = createCenter EAST;
_grp = createGroup EAST;
_tmp = [markerPos "posGlbSpawn2", 180, "LandRover_SPG9_TK_EP1", _grp] call BIS_fnc_spawnVehicle;
//[_grp] call BIS_fnc_spawnCrew;
_wp = _grp addWaypoint [markerPos "wpBrdm", 0];
_wp setWaypointType "GUARD";
//_wp setWaypointBehaviour "COMBAT";
//_wp setWaypointCombatMode "RED";

After Squint tuning :

private ["_grp","_wp"];
_grp = createGroup EAST;
[markerPos "posGlbSpawn2", 180, "LandRover_SPG9_TK_EP1", _grp] call BIS_fnc_spawnVehicle;
_wp = _grp addWaypoint [markerPos "wpBrdm", 0];
_wp setWaypointType "GUARD";	

You raise a valid point with sentenceId I got this error while checking BIS official mission, so when Squint highlight this type of error, what would be the solution to fix it? If I understand correctly Squint analyses all the files and find code not-related in any of the files.

For the average mission maker we have no clear structure to build missions and spend big time trying, checking forums etc... it's complicated by the fact that each files communicate with each others but we don't have a visual scheme or mental image...

Thanks for your work :thumb:

Share this post


Link to post
Share on other sites
Right then ruebe, the colour-choosers in the editor settings page now have a little button labelled '...' which can be used to bring up the standard colour dialog ...

Yeah, that's nice. Though IMHO you could remove the namelist/dropdown-box now alltogether and just display a rectangle with the currently choosen color. Nice and simple. But as you like. :)

Second, and this is more important, once you startup the color picker, the currently selected/defined color needs to be repicked, which currently doesn't happen.. so it's currently a bit of a hassle to find the "sweet spot" of a color, since you can't slightly adjust the last picked one... should be no big deal to pass the initial color to the picker I guess :)

... so I expect to see some 'perfect' colour schemes from you now :p

Ahahaha, I should have known that I'm driving myself into trouble again with my big and dirty mouth, hahaha... :D

Ok, here's another one. In honour of the flaming one, I call this composition "the frozen jerk":

<Codeview>
<FontName>
	Consolas
</FontName>
<FontSize>
	11
</FontSize>
<Background>
	Snow
</Background>
<Highlight>
	AliceBlue
</Highlight>
<Default>
	Black;Regular
</Default>
<Comment>
	ff918d4f;Regular
</Comment>
<LocalVar>
	ff0261ae;Regular
</LocalVar>
<GlobalVar>
	ff02266a;Regular
</GlobalVar>
<Operator>
	Black;Regular
</Operator>
<String>
	ff525252;Regular
</String>
<DeffedOut>
	ffa6a6a6;Strikeout
</DeffedOut>
<Macro>
	ff8d8d8d;Regular
</Macro>
<Other>
	White
</Other>
<OtherFontName>
	Consolas
</OtherFontName>
<OtherFontSize>
	9.25
</OtherFontSize>
</Codeview>

It's a classy one.

Enjoy :D

oh, and here is the "real" flaming jerk, hehe:

<Codeview>
<FontName>
	Consolas
</FontName>
<FontSize>
	11
</FontSize>
<Background>
	Snow
</Background>
<Highlight>
	AliceBlue
</Highlight>
<Default>
	Black;Regular
</Default>
<Comment>
	ff918d4f;Regular
</Comment>
<LocalVar>
	ffe62e00;Regular
</LocalVar>
<GlobalVar>
	ff840003;Regular
</GlobalVar>
<Operator>
	Black;Regular
</Operator>
<String>
	ff525252;Regular
</String>
<DeffedOut>
	ffa6a6a6;Strikeout
</DeffedOut>
<Macro>
	ff8d8d8d;Regular
</Macro>
<Other>
	White
</Other>
<OtherFontName>
	Consolas
</OtherFontName>
<OtherFontSize>
	9.25
</OtherFontSize>
</Codeview>

and a final one for now.. "We're in the money" hahaha:

<Codeview>
<FontName>
	Consolas
</FontName>
<FontSize>
	11
</FontSize>
<Background>
	fffffffd
</Background>
<Highlight>
	ffffff80
</Highlight>
<Default>
	Black;Regular
</Default>
<Comment>
	ffc1ab53;Regular
</Comment>
<LocalVar>
	ff737807;Regular
</LocalVar>
<GlobalVar>
	ff0e7610;Regular
</GlobalVar>
<Operator>
	Black;Regular
</Operator>
<String>
	ff60613a;Regular
</String>
<DeffedOut>
	ffa6a6a6;Strikeout
</DeffedOut>
<Macro>
	ff8d8d8d;Regular
</Macro>
<Other>
	White
</Other>
<OtherFontName>
	Consolas
</OtherFontName>
<OtherFontSize>
	9.25
</OtherFontSize>
</Codeview>

---

oh, there's one more thing: I've tried to do one with a dark background color. The problem is that the operator-color doesn't affect syntax (parenthesis, semicolons and stuff) and numbers... so these characters stay black, which obviously doesn't work with a dark background.

But I guess you've decoupled these already from the "Operators"-color, but haven't put the new catogeries into the code-window panel from the Colours and font selection yet... right?

Edited by ruebe

Share this post


Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
Sign in to follow this  

×