Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 09/28/2020 in all areas

  1. this is what I started to do, store Status as “RUNNING”, “PAUSED”, etc. And it does solve the problems I stated above. However, it has two disadvantages over Eval(Enum) that I see: 1) It loses the information stored in the Enum itself - for instance if I want to cycle += thru the statuses or compare > one Status to another. Not all my iniFile values are like this but some definitely are. 2) There is error checking built in with Eval. String values that don’t match variable names set @error. For arbitrary strings however, I would have to write a function to check against some list of strings myself. Considering this, and considering that the visual difference between String constants and Eval(Enums) is just the word Eval around the function, it seemed appealing. In any case, I appreciate your point of view, and thank you for making me think through in more detail my thoughts!
    1 point
  2. I totally understood the reasoning behind it from the start. Like I said, I use enums a lot too -- as you can see in my UDFs. I guess what it really boiled down to, for me, is that I'm just not a big fan of the Eval function and I try to avoid it unless absolutely necessary. If you have to use it to reference and de-reference your ini values, it just seems to add unnecessary complexity and obfuscation. If it were me, I would store the integer values in the ini file and use the enums for the setting and testing of the ini values in the script. Storing the values as enums, for my taste, is a bit much. But it is just one old guys opinion. As for the reasoning as to how it helps you as a solo coder, if you prefer to quickly be able to identify string-based status values (running, stopped, paused. etc.) in your ini file, because you frequently need to read it manually, then why don't store them that way and let the script handle how they are set and tested? That way you can't forget what the values are and can add new values as needed and without having to worry about existing values. In other words, your example my be a better fit for constants instead of enums. If you are storing the values as strings anyway, you might as well store them as they need to be and not have to de-reference them with Eval functions and thereby remove the unnecessary complexity and obfuscation.
    1 point
  3. Siwa, Sorry, but that could be written in Klingon for all the sense it makes to me. M23
    1 point
  4. Please have a look at my OutlookEX UDF (link can be found in my signature). Create an HTML mail to add formatting. The _OL_ItemCreate.au3 example script (example 4) explains how to do.
    1 point
  5. Hey everyone, just got back from my 2 month break from posting in this topic, LOL Before you add this project to the long list of other "AutoIt wannabe languages", let me tell you that I am still actively thinking about how to progress forward . As a matter of fact, the reason for the delay is that I got busy with another freelance project and so I haven't been able to concentrate on this project with that and all the other good stuff in life. Today I would like to break the silence by reporting on some progress I made while I was quiet. -- I have started work on the next step of parsing, which is syntactic analysis, i.e taking those tokens and building the actual code tree so that the interpreter/compiler can know what the code is trying to do. Before I could start writing code to do that, I need to get all the tokens in a neat array, so I implemented a linked list to do just that... a linked list is a kind of dynamic array, to which elements could be added/removed easily compared to traditional arrays: https://github.com/DcodingTheWeb/EasyCodeIt/commit/5c43ffd392e8a2c26d9187767298167cf2de66c2 I also modified the output code to work with the new dynamic array instead of getting the tokens one-by-one and printing them without storing anything in the memory, and I have also added a neat feature which lets the user know in advance if there are any unknown tokens in the code, which was previously not possible . Here is some sample output: ConsoleWrite("This script has an unknown token" & @CRLF) % ; Here it is !!! WARNING: Unknown token(s) encountered !!! ---### TOKEN ###--- Type: Word Data: ConsoleWrite ---### TOKEN ###--- Type: Bracket Data: ( ---### TOKEN ###--- Type: String Data: This script has an unknown token ---### TOKEN ###--- Type: Operator Data: & ---### TOKEN ###--- Type: Macro Data: CRLF ---### TOKEN ###--- Type: Bracket Data: ) ---### TOKEN ###--- Type: Unknown Data: % ---### TOKEN ###--- Type: Comment Data: Here it is
    1 point
  6. Manjish

    Disable Close button

    Assuming that u r refering to an Autoit GUI, yes u can disable any button.. Check GuiCtrlSetState() in helpfile.. set this to $GUI_Disable
    1 point
×
×
  • Create New...