BBs19

Hi, try setting the Opt("GUIOnEventMode", 1) before you Include the MetroGUI_UDF.au3.

Hi, I didn't really test it or document anything of that version. I am taking a break at the moment. TV-Show-Manager used the last of my resources I will eventually start programming again and fix MetroGUI UDF. The way I am creating custom lists is nothing special. The main problem is the limitation of Windows. After a certain size, it will stop drawing the items at the bottom and they will end up all at the same spot. I had this problem when I created custom graphs with + 200 Items. So not sure if it is worth adding to MetroUDF.

Finally figured it out. I found two workarounds. First one is to use GUIRegisterMsg like it is suggested in the help file, which would be to prevent using any script pausing commands and return instantly in your WM_COMMAND/WM_NOTIFY. What you would do is basically set a variable to true and return and then check in your main loop if the variable is true and execute the desired function. I find this solution not good tho for my case with a right-click menu, as checking in main while loop can cause some delay if you are already doing other stuff in it and also because you need to add a sleep in the while loop. So how to fix it to work like onevent mode? Register WM_NCACTIVATE or WM_NCPAINT message and it suddenly works for what fkn reason ever GUIRegisterMsg($WM_NCACTIVATE, "_Workaround") Func _Workaround($hwnd, $iMsg, $iwParam, $lParam)     return $GUI_RUNDEFMSG EndFunc

Nope, can't figure it out. The problem exsists without MetroGUI. Same problem when using _ArrayDisplay. Script just hangs up when you start GUIs from WM_Notify. I remember giving up with TV-Show-Manager when I had this problem and it worked all by it self I will need check out a few scripts of mine where it worked, maybe I am missing something. Example script to demonstrate the problem: #include <GUIConstantsEx.au3> #include <GUIListView.au3> #include <WindowsConstants.au3> #include <Array.au3> $MainGUI = GUICreate("Alert", 940, 306, -1, -1, $WS_POPUP, -1) GUICtrlCreateLabel("Alert", 400, 8, 99, 27) $ListView1 = GUICtrlCreateListView("a|n|n|n|x", 2, 48, 936, 217) GUICtrlCreateListViewItem("1|2|3|4|5", $ListView1) GUISetState(@SW_SHOW, $MainGUI) GUIRegisterMsg($WM_NOTIFY, "WM_NOTIFY") While 1 $nMsg = GUIGetMsg() Switch $nMsg Case $GUI_EVENT_CLOSE Exit EndSwitch WEnd Func _RightClick($TicketID) Local $ButtonsArray[2] = ["btn1", "btn2"] _ArrayDisplay($ButtonsArray) EndFunc ;==>_RightClick Func WM_NOTIFY($hwnd, $iMsg, $iwParam, $lParam) #forceref $hwnd, $iMsg, $iwParam Local $tNMHDR = DllStructCreate($tagNMLISTVIEW, $lParam) Local $hWndFrom = HWnd(DllStructGetData($tNMHDR, "hWndFrom")) Local $iCode = DllStructGetData($tNMHDR, "Code") Switch $hWndFrom Case GUICtrlGetHandle($ListView1) Switch $iCode Case $NM_RCLICK _RightClick(0) EndSwitch EndSwitch Return $GUI_RUNDEFMSG EndFunc ;==>WM_NOTIFY

I tested it multiple times, can't reproduce it. Maybe you can test the version i posted on the previous page. I am having the same problem right now I am using WM_NOTIFY but with the same result. It seems like spawning a GUI from registered messages causes a bug. I remember having the same problem with my TV-Show-Manager when I was working on it but it somehow worked suddenly, I don't know what the problem was. I will let you know when I figure it out.

TV-Show-Manager is a small, easy to use application that manages all your favorite tv shows. It is a perfect program for you, if you like watching many tv-shows and need help with keeping track of the airdates and times. Features Manage all your favorite TV-Shows with a single program See all airing times of your shows and how many days/hours/minutes you have to wait for the next episode Don't get confused with all the time zones, TV-Show-Manager converts the airing times to your timezone TV-Schedule - See what shows will be airing in the next 48 hours in US an UK Windows 10 inspired user interface - Customize the user interface with different themes See if your favorit tv shows are canceled or renewed with colored status in your list. Download episodes with one click! (Warning: See notes in full description) Supports link collection for one-click hosters and torrents. (Warning: See notes in full description) Stream episodes with one click (Warning: See notes in full description) I have completely rewritten the program over the past months. It uses the latest version of my MetroGUI UDF and demonstrates what you can do with Autoit if you put in enough time You can download the script and the main program from sourceforge. I have removed all download link collection and other anti-bot-protection bypass features from the script that might be used to damage the site owners. So please don't ask for any of these functions on this forum. Images: Download Script and Main program: https://sourceforge.net/projects/tvshowcountdown/files/

Hi, you can use it however you like in your project..You also don't need to set any link in your program.

I think that is a great idea. I started this project back in 2014 when I was still learning the basics and it grew bigger every year with all the new features. The time for a complete rewrite is overdue. At least 1/4 of the code can probably be removed easily. I am sure that you will also be able to easily implement many of the requested features given your previous projects I wish I had the time now to rewrite it with the DllStructs we talked about, to save you the time of trying to understand it, but I guess that will take some time and might take a few weeks or months depending on my motivation and freetime. I have attached the latest unfinished version with multiple bug fixes and some new features that I added while working on another project. Let me know if you need anything. MetroGUI-UDF.zip

I disagree in some parts.. AutoIt might be complete/finished for what it was intended for, but it is simply not perfect for big projects due to lack of native OOP and even though there are many workarounds for this, I would still prefer native support.. But this is not something you can blame the developers for, it is their choice and they have reached more than they probably ever intended for AutoIT. And yes ofc I ment multithreading Also disagree here. Just because you didn't need multithreading in your projects, doesn't mean that others don't need it. As a simple example: When you do a HTTP request to a server that requires authentication and Windows fires up the "Enter your Pin" message, your script will become completely unresponsive, no matter if you use the asynchronous for the HTTP object or not. Now you would need yet another instance running in order to auto-enter the PIN. And I am sure others would also disagree here, especially those who like playing around with GDI+. I have not much experience in C# but I usually hear that AutoIt is pretty slow compared to it. So let's be honest, we are all just using AutoIt because it is pretty easy and allows fast development because there are already so many UDFs

As stated before, im planning on rewriting the UDF to throw out all the unnecessary trash that makes adding new things and fixing problems too difficult. It started out as a simple script for modern buttons with hover effects and grew over time into a huge mess. However this UDF is currently not on my prio list and I am not sure when I will have the time to finish it. As @Earthshine stated, there are better solutions for modern apps. Creating everything from scratch is just too time consuming. Another project I started ended up in a mess with hundreds of workarounds where I spend days trying to make basic things work and all of it just to get a "modern" looking app. It worked out eventually but so much time was wasted that I could have just used to learn other languages AutoIt seems a bit dead to me, just look at the time it was last updated, no more updates, no new features, no multitasking. ..

I don't know what you mean. If i restore it from the tray, it works instantly. Do you have an example with normal gui and metro gui?

Well I didn't think that they woud be as fast as arrays but I hoped that they would not cause such impact either. And you are right, it works for most cases without any impact, but you have to test it out with each case, with arrays you don't have to think about such problems I was mostly concerned with the GUI effects handler, for example when the GUI gets active/inactive, I need to go very quickly through the controls array (get control type, id and bitmap handle from the same array) and set the buttons to an inactive color, this has to work pretty fast, otherwise it will look like each buttons color changes one by one instead of all at once. But I will need test it out all these cases and implement it everywhere it doesn't cause any impact on the performance.

I have been playing around with DllStructCreate for a while now, I added some of the new features using it, because it clears up the code so well and reduces the complexity. I was planning on changing all functions to only use DllStructCreate.. However after running some tests, I was really dissapointed by the performance of it. Reading and writing data to it takes at least twice as much time as when you are working with arrays. I am thinking of implementing it only for details that don't require performance. Like in this case, adding specific details like text, color etc. in case it has to be accessed later. Im afraid for other things that require high performance like hover checking, other effects, loops etc. I will need to keep using arrays as I want everything as smooth as possible. I wish the performance was the same, it would save so much time and make it easier to change things in the script later Here a test script i wrote to compare the performance. This should demonstrate the problem that would occur when trying to search for something specific in the struct. _Test1() ;ignore first time, startup seems to cause some slowdown _Test1() _Test2() _Test3() Func _Test1() Local $a = TimerInit() Local $TestArray[10] $TestArray[0] = 100 $TestArray[1] = 49 $TestArray[2] = "test test" $TestArray[3] = 89 $TestArray[4] = 2 $TestArray[5] = 231 $TestArray[6] = "Running" $TestArray[7] = "S05E08" $TestArray[8] = "Brooklyn Nine-Nine" $TestArray[9] = "Brooklyn Nine-Nine Brooklyn Nine-Nine Brooklyn Nine-Nine Brooklyn Nine-Nine Brooklyn Nine-Nine" ;Search for something specific in the array [assuming we have to search in 50 of these arrays]. For $i = 0 To 49 If $TestArray[5] = "xxx" And $TestArray[4] = "xxx" Then Return Next Local $TD = TimerDiff($a) ConsoleWrite($TD * 50 & " < Using array with index number" & @CRLF) EndFunc ;==>_Test1 Func _Test2() Local Enum $_x_, $_y_, $_text_, $_b_, $_c_, $_showname_, $_description_, $_showid_, $_show_status_, $_last_episode_ Local $a = TimerInit() Local $TestArray[10] $TestArray[$_x_] = 100 $TestArray[$_y_] = 49 $TestArray[$_text_] = "test test" $TestArray[$_b_] = 89 $TestArray[$_c_] = 2 $TestArray[$_showid_] = 231 $TestArray[$_show_status_] = "Running" $TestArray[$_last_episode_] = "S05E08" $TestArray[$_showname_] = "Brooklyn Nine-Nine" $TestArray[$_description_] = "Brooklyn Nine-Nine Brooklyn Nine-Nine Brooklyn Nine-Nine Brooklyn Nine-Nine Brooklyn Nine-Nine" ;Search for something specific in the array [assuming we have to search in 50 of these arrays]. For $i = 0 To 49 If $TestArray[$_showid_] = "xxx" And $TestArray[$_c_] = "xxx" Then Return Next Local $TD = TimerDiff($a) ConsoleWrite($TD * 50 & " < Using array with variables for index number" & @CRLF) EndFunc ;==>_Test2 Func _Test3() Local $ReadArray[50] Local $a = TimerInit() $oTest = DllStructCreate("int x;int y;wchar text[5];int b;int c;int showid;wchar ShowStatus[20];wchar ShowName[80];wchar ShowDescription[500];wchar lastEpisode[20]") $oTest.x = 100 $oTest.y = 49 $oTest.a = "test test" $oTest.b = 89 $oTest.c = 2 $oTest.showid = 231 $oTest.ShowStatus = "Running" $oTest.ShowDescription = "Brooklyn Nine-Nine Brooklyn Nine-Nine Brooklyn Nine-Nine Brooklyn Nine-Nine Brooklyn Nine-Nine" $oTest.ShowName = "Brooklyn Nine-Nine" $oTest.LastEpisode = "S05E08" ;Search for something specific in the struct [assuming we have to search in 50 of these structs]. For $i = 0 To 49 If $oTest.showid = "xxx" And $oTest.c = "xxx" Then Return Next Local $TD = TimerDiff($a) ConsoleWrite($TD * 50 & " < Using DLLStructCreate" & @CRLF) EndFunc ;==>_Test3 These are the time results in ms (assuming we would need to search like this 50 times): 1.44351389605678 < Using array with index number 1.66067970342815 < Using array with variables for index number 3.25748711057061 < Using DLLStructCreate Seems like not much of a difference but depening on how much data you need to store&read and how often, it can make a lot of difference. I used dllstruct like this it in another project for tv shows (storing details about the tv show, episodes etc.) and there was a difference of 30-40ms in the startup time compared to using arrays.

Not possible at the moment, you would need to "move" all controls of the GUI to the right anyway. Horizontal menu might come some day, no gurantees yet. Your answer is on the same page few posts above Not possible at the moment. I planned it for later time when i rewrite the basics of the UDF. -> I am currently working on another project. At the same time I am fixing bugs and adding some new features to the MetroUDF that i need for my other project. I don't have enough time to add complex new features to the MetroUDF at the moment. But I am for sure not finished with this UDF yet

The HiWord in wParam is different when disabling and clicking, you are not checking that in your script. Try this: Func _WM_COMMAND($hWnd, $msg, $wParam, $lParam) If BitShift($wParam, 16) = 0 And BitAND($wParam, 0xFFFF) = $sStopButton Then $stop = True _CheckStop() EndIf Return $GUI_RUNDEFMSG EndFunc ;==>_WM_COMMAND

I will check it out later. Oh damn the automated handling of the control buttons keeps causing problems.. The first v5 fullscreen was working fine. It must have sneaked in after the bugfixes, i haven't noticed as I am handling it manually for my programs. I will fix it with the next update, for now you can do this: Global $ControlBtnsAutoMode = False;Set automode off ;Handle the click manually. Case $GUI_FULLSCREEN_BUTTON, $GUI_FSRestore_BUTTON _Metro_FullscreenToggle($Form1) ConsoleWrite("Fullscreen toggled" & @CRLF)

Hi Melba, do you also know a way to color the background that is behind the headers? If I resize the headers, the background of the main ListView seems to be white

Why don't you use one of the methods used in the example files? One is with OnEventMode and the other is a normal while loop. Your example also works fine for me. I used the example file for this UDF and added your code for a specific button. GUIRegisterMsg($WM_COMMAND, "_WM_COMMAND") Func _WM_COMMAND($hWnd, $msg, $wParam, $lParam) If BitAND($wParam, 0x0000FFFF) = $Button1 Then MsgBox(0, "", "") EndIf Return $GUI_RUNDEFMSG EndFunc ;==>_WM_COMMAND You can't edit the text of buttons as they are pictures, they need to be recreated to edit the text. I might add this later, but for now you can use two buttons and hide one if you for example want a button that switches between Start / Stop

Yes you can use more than one time according to the help file.

Hi, I tested it again and it is a bug in the internal exit function which starts deleting the GUIs from 0 to x instead of from x to 0. Please replace the following function with the one from the MetroGUI_UDF.au3 Func _iMExit() For $i_HR = UBound($iGUI_LIST) - 1 To 0 Step -1 _Metro_GUIDelete($iGUI_LIST[$i_HR][0]) Next DllCallbackFree($m_hDll) _GDIPlus_Shutdown() EndFunc ;==>_iMExit I will update the UDF later

Wow, that looks really nice, great work! I will check out the code and try to build it in with the next version. Keep em coming if you have more custom controls

Hi, You can just use "Exit" if you want to close the program, all resources will be released when exiting, there is a OnExit registered by the UDF, _Metro_GUIDelete is only required if you want to close a specific GUI while working with multiple GUIs. New version released. The v5 update created quite some bugs. Slowly fixing all bugs I find while using the UDF in another project and also adding some new things that should have been there in the first place, like _Metro_ToggleSwitch and _Metro_CheckboxSwitch > Also added support for the OnEventMode, see included example on how to use. Ps.: You can simply edit things like font, buttonstyle etc. for functions like _Metro_MsgBox in the main UDF. I prefer not to add 100 parameters for every function to allow 100% customization.

Doesn't work instantly because the metro controls are just pictures, they can't be changed without recreating them. You can either restart the program or you can delete the old controls and recreate them after setting the new theme. As for the background of the GUI, you can update it using GUISetBkColor($GUIThemeColor, $Form1) after changing the theme.

Seems to be working fine, thanks. What a strange bug tho...