Jump to content

Simple control without endless while loop?


ppat
 Share

Recommended Posts

Hi,

I want to make a very simple control with 2 buttons. The control window never closes unless clicking on the top right x. When one button is clicked, it will change a value in an .ini file.

My code looks like this

; Run the GUI until the dialog is closed using the top right x

While 1

$msg = GUIGetMsg()

Select

Case $msg = $GUI_EVENT_CLOSE

ExitLoop

Case $msg = $Button_1

; Change the ini file here using IniRead, IniWrite

Case $msg = $Button_2

; Change the ini file here using IniRead, IniWrite

EndSelectWEnd

I click on one of the buttons maybe once, twice a day, but the control remains open all day long. I recently noticed that at the end of the day, the performance of my PC decreases. I wonder if it is due to this program and the while loop executing in the background for a full day. Is there a better way to do this than using the infinite while loop?

Link to comment
Share on other sites

I think there is another way that's called Event Mode(I'm not sure, I can hardly remember..)

You can try insert Sleep(10) just before the Wend.. It can reduces mamory usage...

Edited by Mison

Hi ;)

Link to comment
Share on other sites

  • Moderators

ppat,

You must have an infinite While...WEnd loop somewhere in your script or it ends! And this is true in MessageLoop and OnEvent mode.

I strongly doubt that it is your script that is causing your perceived "slowdown" problem, but there are a couple of basic things you can do to see if it is giving you a problem:

Once you have launched your script, open Task Manager and look at the information for your script under the "Process" tab. Note the CPU and Memory(Private Working Set) values. At the end of the day - when you sense the PC is sluggish - look again at these values.

The CPU figure shows how much of the processor you are using. With a GUIGetMsg() in your loop, you should be down at 0-2. I do not really expect this to change with time - but you never know!

The Memory number shows how much of the limited (a relative term) amount available your app is using. If you are using the standard Autoit functions to do your ini stuff you should not have problem with memory leakage - but this is a way to check. If the number has increased markedly, then you should post your code so we can try and see where the problem might lie.

Of course, you might like to do the same thing for the other processes running - you may well find the culprit elsewhere! :)

M23

Public_Domain.png.2d871819fcb9957cf44f4514551a2935.png Any of my own code posted anywhere on the forum is available for use by others without any restriction of any kind

Open spoiler to see my UDFs:

Spoiler

ArrayMultiColSort ---- Sort arrays on multiple columns
ChooseFileFolder ---- Single and multiple selections from specified path treeview listing
Date_Time_Convert -- Easily convert date/time formats, including the language used
ExtMsgBox --------- A highly customisable replacement for MsgBox
GUIExtender -------- Extend and retract multiple sections within a GUI
GUIFrame ---------- Subdivide GUIs into many adjustable frames
GUIListViewEx ------- Insert, delete, move, drag, sort, edit and colour ListView items
GUITreeViewEx ------ Check/clear parent and child checkboxes in a TreeView
Marquee ----------- Scrolling tickertape GUIs
NoFocusLines ------- Remove the dotted focus lines from buttons, sliders, radios and checkboxes
Notify ------------- Small notifications on the edge of the display
Scrollbars ----------Automatically sized scrollbars with a single command
StringSize ---------- Automatically size controls to fit text
Toast -------------- Small GUIs which pop out of the notification area

 

Link to comment
Share on other sites

Hi,

I want to make a very simple control with 2 buttons. The control window never closes unless clicking on the top right x. When one button is clicked, it will change a value in an .ini file.

My code looks like this

; Run the GUI until the dialog is closed using the top right x

While 1

$msg = GUIGetMsg()

Select

Case $msg = $GUI_EVENT_CLOSE

ExitLoop

Case $msg = $Button_1

; Change the ini file here using IniRead, IniWrite

Case $msg = $Button_2

; Change the ini file here using IniRead, IniWrite

EndSelectWEnd

I click on one of the buttons maybe once, twice a day, but the control remains open all day long. I recently noticed that at the end of the day, the performance of my PC decreases. I wonder if it is due to this program and the while loop executing in the background for a full day. Is there a better way to do this than using the infinite while loop?

Hi,

AutoIt can use an "events mode" so the script does not have to do while loops. Internally, AutoIt still does the while loop, but this in the C++ code (makes no difference, in the end). Using events mode will not solve your problem.

The script you have written has no long term performance issues on your computer. You can try this out for yourself, simply don't run the script and see how your PC is behaving after a full day. I can already predict the outcome with a vast amount of certainty: Your script is fine.

You shouldn't worry about these things.

Link to comment
Share on other sites

Oh, come on, I've got that from Manadar you know.. :) about that Sleep(10)

I never said that.

1. GUIGetMsg() has an in-built sleep. When you are calling it in a loop, you don't have to additionally call a sleep.

2. Sleep can help fast loops that do polling to slow down. For example, in a TCP server when you are waiting for clients.

Link to comment
Share on other sites

You never said that? ermmm... Seems like I had misinterpreted your post here... Post

After read that post, I was really thinking that Sleep = less mamory... I guess I was wrong in that assumption

I'm sorry ok...

Edited by Mison

Hi ;)

Link to comment
Share on other sites

In the past, I've used the sleep trick to cut down on CPU usage. The real cause was badly written code on my part, but then again one has to remember coding is an art, and a dark art at that. I could give a piece of code to one of the MVPs, and I'm sure they could make it different, but do the same thing. What they do may not be better, but it would work. Personally, I would not criticize one person's preference in using it.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...