Leaderboard

I started this JSON library back in late 2007, because I needed a way to pass structured data between Javascript HTAs and AutoIt3 scripts. I've recently worked to get it in good enough shape to share with the AutoIt community, and while it still needs a bit more polish, the core functionality should be solid. Three files are included in the attached archive: JSON.au3 – the UDF Library itself. It includes a (very large) comment section at the top, which should provide sufficient documentation on how the various data types are encoded and decoded, as well as the various Javascript-based decoding extensions allowed (single-quoted strings, comments, etc.).JSON_Translate.au3 provides example functions for the powerful "translator" functionality. Translator functions can be used for both encoding and decoding. When encoding, it allows you to recursively convert your data from its normal format into the required data structures used by the JSON UDF library. When decoding, it allows you to convert the data in the opposite direction – from the JSON UDF library's data structures to the data structures your program normally uses. To use this functionality, you'll need to write your own translator functions, but this allows you to meet the custom needs of your own programs without having to hack JSON.au3. The examples provided in this file can probably be improved, but show one way of translating AutoIt-specific data types (such as binary and hwnd) back and forth.testJSON.au3 provides some quick examples of regular and translator-enhanced usage, which also help verify that encoding and decoding are working properly. These tests may not be comprehensive.The area needing the most work is error-handling. JSON data structures can be deeply nested, and it's tricky to make sure errors "bubble up" properly in AutoIt. (Plus, I need a flowchart to keep track of all my setError() numbers!) Thanks to Douglas Crockford of JSON.org, whose 2005 Javascript code for JSON encoding and decoding provided an excellent starting point for this library. Edit: updated to 0.9.1 on 2009-10-19 substantially updated opening commentsencoding: implemented logic to return "warning" @error flags for unsupported variable types & JSON objects with non-unique key stringsother minor fixes & tweaksJSON.7z

If you want to avoid a flicker and use GDI+ you would normally use what's called a buffer (it's an object [graphic object] linked to a bitmap). When you draw on the graphic you're drawing on the bitmap, then you draw the bitmap on your main graphic. #include <GDIPlus.au3> #include <GUIConstantsEx.au3> #include <GUIConstants.au3> HotKeySet("{Esc}", Close) Local $hGUI, $hGraphic, $hBrush, $hFormat, $hFamily, $hFont, $tLayout Local $iString = 0 Local $aStrings[3] = ["Testing 123" & @CRLF & "I've got info for you" & @CRLF & @CRLF & "And that is not all!", _ "Another page" & @CRLF & "this is more text." & @CRLF & "More to come.", _ "The last page" & @CRLF & @CRLF & "this is more text." & @CRLF & "And that IS all."] ; Create GUI $hGUI = GUICreate("", 400, 300, -1, -1, $WS_POPUP) GUISetBkColor(0xFF000000) ; will change background color GUISetState(@SW_SHOW) ; Draw a string _GDIPlus_Startup() $hGraphic = _GDIPlus_GraphicsCreateFromHWND($hGUI) Local $hBitmap = _GDIPlus_BitmapCreateFromGraphics(400, 300, $hGraphic) Local $hBuffer = _GDIPlus_ImageGetGraphicsContext($hBitmap) $hBrush = _GDIPlus_BrushCreateSolid(0xFF99ff33) $hFormat = _GDIPlus_StringFormatCreate() $hFamily = _GDIPlus_FontFamilyCreate("Arial") $hFont = _GDIPlus_FontCreate($hFamily, 20, 0) $tLayout = _GDIPlus_RectFCreate(50, 50, 0, 0) While (True) Local $aInfo = _GDIPlus_GraphicsMeasureString($hGraphic, $aStrings[$iString], $hFont, $tLayout, $hFormat) _GDIPlus_GraphicsClear($hBuffer) _GDIPlus_GraphicsDrawStringEx($hBuffer, $aStrings[$iString], $hFont, $aInfo[0], $hFormat, $hBrush) _GDIPlus_GraphicsDrawImage($hGraphic, $hBitmap, 0, 0) Sleep(200) $iString += 1 If ($iString > 2) Then $iString = 0 WEnd ; Clean up resources Func Close() _GDIPlus_FontDispose($hFont) _GDIPlus_FontFamilyDispose($hFamily) _GDIPlus_StringFormatDispose($hFormat) _GDIPlus_BrushDispose($hBrush) _GDIPlus_GraphicsDispose($hGraphic) _GDIPlus_Shutdown() EndFunc ;==>Close

As I told you before, you are atempting to encrypt your source, not obfuscate it. If you want to obfuscate your source, you should tick the appropriate option checkbox in CodeCrypter. I just explained to you in my previous post how to set up an encryption for a target machine other than the one upon which you encrypt your source; press the Decryptor button and define the expected response for the defined key in the target environment. The purpose of CodeCrypter is to generate a script that runs only in a sanctioned environment. How you define what constitutes that environment is entirely up to you. The whole point is that the decryption key is derived from that environment at runtime, so anyone can copy your script/exe, but it won't run anywhere else than wherever the work environment returns a valid decryption key. So I'd advise you to use a key definition (or several) that is specific to that VM. But if you really want to disable this essential safety feature, you can always encrypt with macro @ScriptName as key. See posts #45 and #46 for detailed instructions (and please note the difference between running the .au3 from Scite and compiled exe!) For more info, please read the extensive FAQ I provided, and run lots of tests by using different key definitions (these can also be your own function calls, not just macros). That should be enough to get you started, now that we've established that CodeCrypter was working fine all along.

argumentum, Edit: I just googled wetware :D:-) Yup. The gray stuff. On the Win98 "issue", when I revamped the script-o-matic , there were questions of why support for Win98, and this post proves it is useful :) It was not so much if Win98 should be supported, but why a version of autoit which was said to support it wouldn't work on that OS. Seaching for the error message (as I posted it) didn't work for me, but doing so for "AutoIt3A.exe" did. It brought me back to this forum, which showed me that the "A" versions are the ANSI versions, and the ones without that letter actually being the "W" -- for wide-character -- versions. And as Win98se does not truly support wide-character its no wonder those executables failed to work. Putting a few rather non-obvious lines into one of SciTEs configuration files would tell SciTE to use the "A" versions, which worked well. Question remains to why the downloads did not contain any warning/explanation to the above, nor what to do to "fix" it for Win9x. :-( I believe that since LAN IP is not the WAN IP, and that, if no mapping is done to open a port from the outside, no firewall is needed, as there is no routing.I assume that you are talking about your modem there ? Than indeed, no port-forwarding means that an active attempt cannot be made. But that does not protect you from someone sending tampered data back on a (webpage?) request you did to the 'net. And that data does indeed reach your 'puter, and can try to cause buffer overflows and more of that ilk. And virus has to find a way to execute, either via social engineering or a service ( being java and javascript ) executing it.Not always. Some programs that are used to run certain web-based content can have abusable bugs, meaning that if you visit a website with such data you can be infected without you doing anything special (hint: Flash :-) ) Now, if these "executors" don't behave as default and one does not go and run it, how else a virus can load/run in a personal house network ? Do you ever save/store stuff from the 'web or other people onto your'puter ? Than you can be infected that way. Word textfiles can be stuffed with malicious macros. PDF files idem. Even some image handlers have flaws which can be explooited by just looking at a stored image. Worse: some (old, Microsoft) image formats seem to have been deigned to be abused. Just take a look at the .WMF format (which allowed executable code to be embedded, to catch send-to-printer failures). Also, don't forget that if you have a "weak" device in your LAN (WIFI security cams and stuff like it or even just a WIFI router (for your phone and/or slabs) ) that it could be used to "smuggle " the attack onto your LAN, bypassing the ISPs router defenses ... Also, some viri infect USB sticks (or other media like it), and by that way let themselves be transported from one computer to the next. 'm willing to go as far as setting up a Win98 VM to prove its dangerousness Any OS can be dangerous in yhis regard -- though (Linux seem to have a good track record :-) ). Disclaimer: This is all in good fun for me, I'm curious and would welcome the exploratory experience. Same kind of disclaimer here: I'm not a professional, nor have I made an actual study of the subject.

In a perfect world, sure--if no one does anything to compromise a system locally and there is no direct internet connection and safe browsing habits are used, a system is "safe". Even outside of these conditions there are risks: modems/firewalls can be targeted and attacked allowing the attacker the ability to traverse/access the internal network(s). Drive-by-downloads can occur, even on reliable and safe websites if they are compromised, DNS poisoning comes to mind as well. Now these issues are not specific to any OS, but the fact that an obsolete OS is in use and is no longer maintained (patched) means much greater risk. The internet can be a dangerous place.

#include <File.au3> #include <GUIConstants.au3> #include <Array.au3> Global $aButtonIds = _FileListToArray("C:\test\", "*.*", $FLTA_FILES) Global $hGui = GUICreate("Edit Get Text", 400, 300) Global $aButtons[_ArrayDelete($aButtonIds, 0)] For $i = 0 to UBound($aButtonIds) - 1 $aButtonIds[$i] = GUICtrlCreateButton($aButtonIds[$i], 10, 10 + ($i * 30), 100, 20) Next GUISetState(@SW_SHOW, $hGui) While (True) Local $iMsg = GUIGetMsg() Switch ($iMsg) Case $GUI_EVENT_CLOSE Exit 0 Case Else For $i = 0 to UBound($aButtonIds) - 1 If ($iMsg = $aButtonIds[$i]) Then MsgBox("", "", "Button " & GUICtrlRead($aButtonIds[$i]) & " pressed") ExitLoop EndIf Next EndSwitch WEnd

That's exactly what I'm doing, @nikink, though, you outta agree this is a great jury-rig I got the script running and getting me results already. I would like to find a solution, though. Or at least understand that behavior.