Jump to content

dinodod

Active Members
  • Posts

    245
  • Joined

  • Last visited

About dinodod

  • Birthday 12/03/1974

Profile Information

  • Location
    Fl, USA

Recent Profile Visitors

673 profile views

dinodod's Achievements

Polymath

Polymath (5/7)

2

Reputation

  1. In that case, is there any official UDF database with a help file that can list the more useful / popular ones?
  2. Guys & Gals, This is by far my most beloved tool for making solutions that work. The # of people expanding the capabilities and functions in this tiny little tool is beyond amazing and I hope this continues to grow with more Win 10 & beyond solutions. With that being said, I feel there are some much needed updates that should be considered to be part of the native Autoit toolkit. It took these members some time to develop and test these solutions and credit to all of them for their contributions, including those that helped. "There is no I in TEAM". With that, I want to know if Autoit & Autoit help will ever natively support high DPI? It's quite an eyesore now to look at the helpfile on a 4k 50" monitor While I found several solutions to this, the one that worked for me was a simply 1 line ;High Re support If @OSVersion = 'WIN_10' Then DllCall("User32.dll", "bool", "SetProcessDpiAwarenessContext" , "HWND", "DPI_AWARENESS_CONTEXT" -2) Credit: Shark007 (Link) In addition, Databases are a staple of most programmers and while SQLITE is a nice DB, what about natively supporting SQL, MySQL, Postgres, Access, etc? The amazing ADO.UDF, while in Beta at this time, is quite powerful and should be looked at to see if it could be natively included to allow for more options to use other databases. Credit: mLipok (link) What about any new features / functions to Autoit itself? 3.3.14.5 (16th March, 2018) (Release). Would love to see a new fresh release with tons more addons and updated tools. I'm getting worried this is going to become vaporware and lose support, which, let's face it, would be absolutely horrible to all of us. Many thanks to everyone who has spent so much of their time supporting this and their fellow programmer / scripters / etc.
  3. This is exactly what we needed.... Not sure if I also needed the new beta autoitwrapper but I have that too... Now here is the next question.... Will this confuse the app on low res monitors? do I need separate versions now?
  4. Ok, so per the docs, the CC machine uses port 10000 to send data to it & 10001 to receive data from it. Is there anything odd about my approach? Mind you, I used the example help file script and modified it to test it. It appears that I can send the command ok as I don't receive an error but I can't seem to listen for the response.... Func MyTCP_Client($sIPAddress, $iPort) ; Assign a Local variable the socket and connect to a listening socket with the IP Address and Port specified. Local $iSocket = TCPConnect($sIPAddress, $iPort) Local $iError = 0 ; If an error occurred display the error code and return False. If @error Then ; The server is probably offline/port is not opened on the server. $iError = @error MsgBox(BitOR($MB_SYSTEMMODAL, $MB_ICONHAND), "", "Client:" & @CRLF & "Could not connect, Error code: " & $iError) Return False EndIf ;Get Version $x='{"jsonrpc": "2.0", "method": "GetVersion", "params": {"component": "Reader"}, "id": 127}' TCPSend($iSocket, $x) ; If an error occurred display the error code and return False. If @error Then $iError = @error MsgBox(BitOR($MB_SYSTEMMODAL, $MB_ICONHAND), "", "Client:" & @CRLF & "Could not send the data, Error code: " & iError) Return False Else msgbox(0,"","No Error found. Listening for response") Local $iListenSocket = 10001 Do ; Wait for someone to connect (Unlimited). ; Accept incomming connections if present (Socket to close when finished; one socket per client). $iSocket = TCPAccept($iListenSocket) ; If an error occurred display the error code and return False. If @error Then $iError = @error MsgBox(BitOR($MB_SYSTEMMODAL, $MB_ICONHAND), "", "Could not accept the incoming connection, Error code: " & $iError) Return False EndIf Until $iSocket <> -1 ;if different from -1 a client is connected. msgbox(0,"","Listening for data is complete") ; Close the Listening socket to allow afterward binds. TCPCloseSocket($iListenSocket) EndIf ; Close the socket. TCPCloseSocket($iSocket) EndFunc ;==>MyTCP_Client
  5. I think you are trolling me LOL. And yes, the example script does work but it's a simple script to test the commands. What I am more interested in is if anyone has more experience using Autoit to manage a PLC and what is involved. I could show you the mappings of all the databanks and such on the PLC itself if you want Math... I'm not sure how to properly read / write to the databanks on the PLC using autoit and I don't want to smoke the PLC with the wrong commands. It's like doing brain surgery with a manual and no experience. Not recommended...
  6. I have a siemens PLC (Not sure on the model atm) and I was wonering if anyone has ever developed an app to communicate with a PLC before. It used TCP for the connection but I'm not sure if Autoit can truely manage a PLC or not. The app that was given to me is in C# which works but I'm not a C# dev and that code confuses the heck out of me, so I was hoping to see how hard / easy it would be to utilize Autoit. Not finding any resources thus far that could help much. Many thanks
  7. So I have a USB Credit card machine that uses JSON 2.0 standard (See bottom of post for the JSON commands). Thus far, I have not yet seen any good examples of how to incorporate the JSON commands properly. I believe I have a working script that can open the ports to the USB device using 127.0.0.1 as the IP address & the correct ports needed using the following URL as an example. Can anyone help me format the commands to properly talk to the device? Many thanks! Pre - Authorize >> {"jsonrpc": "2.0", "method": "PreAuthorize", "params": {"amount": 1.50, "currencyCode": 840, "timeout": 60}, "id": 123} << {"jsonrpc": "2.0", "result": true, "id": 123} Get Version >> {"jsonrpc": "2.0", "method": "GetVersion", "params": {"component ": "Reader"}, "id": 127} << {"jsonrpc": "2.0", "result": "040506", "id": 127}
  8. Indeed you can... https://4sysops.com/archives/powershell-remoting-over-https-with-a-self-signed-ssl-certificate/#why-https-with-invoke-command-and-enter-pssession The next issue is how to connect to a remote PC. My guess is that I would have to use a service like DynDNS to host a dynamic DNS record of the remote PCs. Not to mention I would then have to explain or try to configure the client's network to grant access to the PC over SSL / HTTPS. I've tested a couple of RMM apps and they use an agent to manage the connection which makes it super easy.
  9. On a local network sure, but not a remote network.
  10. Has anyone ever needed to connect to a remote PC on a different network to be able to look over the logs and do some work without the need to actually remote into it? I was wondering if anyone could point me to the right direction on how to build an agent that can connect over the internet back home to me. I'm trying to build a RMM for some kiosks that I manage as they are in different locations and no joined by AD or Azure. Thanks!
  11. Again, I don't have a problem installing the updates, we simply do not work on the same schedule as what MS wants. For MS to simply say your pc gets updated by us IS NOT acceptable. This is why I am so upset with everyone's response cause you all are assuming that I will NEVER install these updates which is NOT TRUE. If these updates are of a critical nature due to some flaw that was being exploited at the time, we would rush to install the update(s) as needed. But these updates are NOT critical. They are important, sure, but NOT critical. You are simply bowing down to how MS does business and don't care about your own client's PCs. You simply are shrugging your shoulders and have the "Whatever" attitude which is wrong. You think MS has the best solution which is clearly not true. MS has a LONG history of issues with their updates breaking things and I WILL NOT!! ... WILL NOT!!! ... allow MS to continues to manage my systems their way when the end result cripples PCs and businesses suffer. How there isn't a class act against this form of tyranny is beyond me. So since no one can offer me anything useful, I'm just going to close this thread and walk away. I can't wait till the next flawed update cripples your systems. Thanks for nothing
  12. I do not work for a enterprise environment, rather, a couple small businesses where AD / WSUS / and SCCM are not feasible (See above post). FYI The firewall & GPO are a mute point simply cause MS has circumvented it and I have not found a respectable free firewall to use. However, the default FW policy I use on kiosks is to simply block all inbound / outbound traffic except for the Credit Card machine & Teamviewer. We do update the systems on occasion, just not on MS's schedule.
  13. Then you haven't worked in an environment where MS updates have crippled your USB driver and literally shut down a small business for hours. A small business where AD and WSUS are not an option. Or where you have independent KIOSKS in the field where you have an 1+ hour drive to service in case of a network loss. These are but a few examples where MS has and will continue to cripple service because they feel they can manage your updates for you. They DO NOT care about the fallout THEY cause simple because they don't have to do anything. We have a schedule that we use which does not revolve around MS's timetable. And I will be DAMNED! if MS tells me how to manage the updates. They are not paying us for their fallout and I am quite frankly sick of them doing what they want with no concern. Until you have felt the burden of a small business, don't give me friendly advise on NOT updating Windows.
  14. Very difficult for sure but I'm willing to look into it... While I think I crippled the WAASMedic service atm, the WU service was still able to kick on.. This after I deleted the scheduled tasks for WU and the medic.
×
×
  • Create New...