Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 08/20/2025 in all areas

  1. UEZ

    DLL Call Problems

    Made a quick test with 3.3.12.0 by replacing AutoIt3.exe only - same result.
    2 points
  2. I've wasted time as well. I've on creating microsecond sleep periods. I've copied and implemented a few things I learnt on here, that use Microsoft com objects, but the COM object does not reliably do what it says it does. Only by testing and measuring did I gain certainty. Same with random number functions for any language. Computers don't do random. They are anything but random. So I have had to build my own. Did it 30+ years ago in C. Did it recently with Autoit.
    1 point
  3. Werty

    DLL Call Problems

    May not be related, but in AutoIt after version 3.3.12 there were things that were broken, like stuff I was able to do in 3.3.12 didnt work in later AutoIt versions, but that was concerning ImageMagick.dll COM object, dont know if that also ruined stuff like your problem. Reference post https://www.autoitscript.com/forum/topic/199781-rgb-imgs-to-cmyk-to-tiff/#comment-1433227
    1 point
  4. UEZ

    DLL Call Problems

    You are lucky. I found a backup file which is dated to 0.4.4 but what is the reason for the request for the older version? V0.4.4 is uploaded to my 1drv.
    1 point
  5. MattyD

    WinRT - WinUI3

    OK I've managed to get this working for the most part... bear with me. say we want to resolve: "Windows.Foundation.Collections.IVector`1<Microsoft.UI.Xaml.Controls.ColumnDefinition>" broadly speaking, this is what needs to happen. Create a MetaDataLocator - this is similar to how we're creating our delegates. It doesn't inherit from IUnknown, and has 1 method called "Locate"... but more on this in a bit! Call RoParseTypeName. This gives us an array of name elements i.e.: ["Windows.Foundation.Collections.IVector`1", "Microsoft.UI.Xaml.Controls.ColumnDefinition"] Use this info to call RoGetParameterizedTypeInstanceIID. As RoGetParameterizedTypeInstanceIID does its thing, it'll pump us for information - by you guessed it! calling our "Locate" function. we are provided with: a name of a typedef and a pointer to an IRoSimpleMetaDataBuilder interface. (I've written an interface library for this one). We need to dig in the metadata for that info, then call the correct method of the builder to send it on. A call to RoGetMetaDataFile will get us an pointer to a IMetadataImport2 interface. This is what we should use to find stuff. In our scenario, the first time "Locate" is called we're asked to resolve "Windows.Foundation.Collections.IVector`1" So we need to determine what this is.. (a paramatised interface). Therefore we should call builder.SetParameterizedInterface(PIID, NumParams). Next time around we get "Microsoft.UI.Xaml.Controls.RowDefinition". This is a class. So this time we should call builder.SetRuntimeClassSimpleDefault(ClassName, DefaultInterface, DefaultInterfaceIID). DefaultInterfaceIID is optional though can be left null. In this case Locate() would be called a third time asking us to resolve the default interface (Microsoft.UI.Xaml.Controls.IRowDefinition). Because this is a non-paramatised interface, we'd then call builder.SetWinRtInterface(IID). Once RoGetParameterizedTypeInstanceIID is satisfied it'll spit out what it thinks the IID is. If we call the wrong method on IRoSimpleMetaDataBuilder or provide bad info, then unsurprisingly we get an incorrect IID as a result! I'll do a bit of a tidy up, and pop some code up in a day or two
    1 point
  6. I'm going to state the obvious. It pays to remember that every process in software takes time. There is no escaping it. The more work and CPU cycles something takes, the longer it is. Even declaring a variable, adding up some numbers, or calling an empty function takes time A lot of the communication apps I write are processing a lot of data, and are waiting for inputs to end, so execution time is important. I build timers into deployed software betas that write to the Windows Event Logs, which get returned to a monitoring console. Sometimes it takes a lot of coding development to cut down on processing time. I don't have a good understanding of Com objects, but some of them do not always work as efficiently and as accurately as we would expect. Everything has to be tested to give certainty.
    1 point
  7. @jugador, guess it is you that made the bug report #4045 ... right? What's up with that last comment in that report, or did we miss any promised SLA in our mutual signed contract?
    1 point
  8. Working example: #include <MsgBoxConstants.au3> #include "wd_helper.au3" _Example() Func _Example() Run('"C:\Program Files\Mozilla Firefox\firefox.exe" --marionette -profile C:\FirefoxTEMP') _WD_Option('Driver', 'geckodriver.exe') _WD_Option('DriverParams', '--log trace --connect-existing --marionette-port 2828') _WD_Option('Port', 4444) _WD_Startup() Local $sSession = _WD_CreateSession() _WD_Navigate($sSession, "https://www.autoitscript.com/forum") MsgBox($MB_OK + $MB_TOPMOST + $MB_ICONINFORMATION, @ScriptName, "After attaching") _WD_Shutdown() EndFunc ;==>_Example
    1 point
  9. https://stackoverflow.com/questions/44277119/how-to-connect-selenium-webdriver-to-existing-firefox-chrome-browser-session
    1 point
×
×
  • Create New...