Buttons enabling despite using textEdited?

GaryN

I have two buttons on my form; both disabled by default.

I have set up my code such that, if any qLineEdit's have their contents changed by the user (and not by my code through setText) then the buttons should become enabled.

However, as soon as I run the code the buttons are enabled.

If I comment out the two lines relating to enabling the buttons, the form appears with both buttons disabled. Yet when I run it normally both buttons are enabled.

I even tried moving the assignment of the signal until after the setText command, but to no avail.

My code as is...

from PySide2.QtWidgets import QLineEdit, QPushButton


def initialise(self):

    dataItems = ['lunit', 'lfile', 'kunit', 'sfile', 'junit', 'ofile']
    self.fv_dict = {}

    self.saveButton = self.window.findChild(QPushButton, 'saveChanges')
    self.discardButton = self.window.findChild(QPushButton, 'discardChanges')

    for dataItem in dataItems:
        self.fv_dict[dataItem] = self.window.findChild(QLineEdit, dataItem)
        self.fv_dict[dataItem].textEdited.connect(textedited(self))

    dataFile = open("stelcor.csv", "r")
    dataList = ""
    for line in dataFile:
        dataList += line.replace("\n", ",").strip()
    dataFile.close()

    items = dataList.split(",")

    for counter, dataItem in enumerate(dataItems):
        self.fv_dict[dataItem].setText(items[counter])


def textedited(self):

    self.saveButton.setEnabled(True)
    self.discardButton.setEnabled(True)

JonB

@GaryN said in Buttons enabling despite using textEdited?:

self.fv_dict[dataItem].textEdited.connect(textedited(self))

I don't think you ought have this. def textedited(self): should be a class member method, not a free function if that is what it currently is. Then it would be

self.fv_dict[dataItem].textEdited.connect(self.textedited)

Don't know if this matters.

I added a simple print() statement to the definition and, when I ran the program, I got 85 print outs of "Test 1". There are 85 QLineEdits in the form.

In which case the slot is being called 85 times, and hence doing the disabling you talked about. I do not know why textEdited signal would be emitted at all if you are not editing the text. As you say, self.fv_dict[dataItem].setText(items[counter]) ought not be raising that signal. Try commenting out that line to see if it is the cause nonetheless.

What version of Qt are you using? If Qt6 then for all I know it might be a bug or change in behaviour.... OIC, PySide2. Make 100% sure you do not have textChanged.connect anywhere?

If you have to do not do the textEdited.connect() loop till after you have done the setText(items[counter]) loop. That might remove your 85 calls? But does not answer why textEdited() seems to have been called when only going setText()?

JonB

@GaryN
Nothing shown in this code is the cause. Show the relevant missing bits.

Where do you initialise the buttons to disabled?
Most importantly, show the connect()s --- any and all --- that you are using relating to textedited() slot and whatever signals.
Put a print() statement as first line in def textedited(self):. Let's see where/when it gets hit, for whatever reason.

GaryN

@JonB

I removed enabled within the form.ui:

I added a simple print() statement to the definition and, when I ran the program, I got 85 print outs of "Test 1". There are 85 QLineEdits in the form.

When I show the Signals and Slots Editor, or the Action Editor, they are both empty.

SimonSchroeder

@GaryN said in Buttons enabling despite using textEdited?:

When I show the Signals and Slots Editor, or the Action Editor, they are both empty.

Still, somewhere (most likely in the Python code) must be a place to connect to textedited(self). Otherwise there wouldn't be any connection between editing the text and this slot. Maybe you connect textChanged() instead of textEdited() or something similar. Most likely, setText() is the "culprit" here. You can use blockSignal() to block/unblock the call to the slot when calling setText(). But, first please understand why the slot is triggered before using this workaround.

GaryN

@SimonSchroeder

Ah, yes, sorry.

In the code given in my OP, in the first loop, I set the connection up...

...

    for dataItem in dataItems:
        ...
        self.fv_dict[dataItem].textEdited.connect(textedited(self))

...

    for counter, dataItem in enumerate(dataItems):
        self.fv_dict[dataItem].setText(items[counter])


def textedited(self):

    self.saveButton.setEnabled(True)
    self.discardButton.setEnabled(True)

It is post this connection that I then setText (though I did try altering the loop assigning the connection so that it ran post setText, but that didn't work).

As you can see, the connection calls the subroutine textedited, which appears after the initial definition.

JonB

@GaryN said in Buttons enabling despite using textEdited?:

self.fv_dict[dataItem].textEdited.connect(textedited(self))

I don't think you ought have this. def textedited(self): should be a class member method, not a free function if that is what it currently is. Then it would be

self.fv_dict[dataItem].textEdited.connect(self.textedited)

Don't know if this matters.

I added a simple print() statement to the definition and, when I ran the program, I got 85 print outs of "Test 1". There are 85 QLineEdits in the form.

In which case the slot is being called 85 times, and hence doing the disabling you talked about. I do not know why textEdited signal would be emitted at all if you are not editing the text. As you say, self.fv_dict[dataItem].setText(items[counter]) ought not be raising that signal. Try commenting out that line to see if it is the cause nonetheless.

What version of Qt are you using? If Qt6 then for all I know it might be a bug or change in behaviour.... OIC, PySide2. Make 100% sure you do not have textChanged.connect anywhere?

If you have to do not do the textEdited.connect() loop till after you have done the setText(items[counter]) loop. That might remove your 85 calls? But does not answer why textEdited() seems to have been called when only going setText()?

GaryN

@JonB
And fixed!

Moved it within the form class instead (as you suggested) and it worked a treat!

Still not sure whay the previous approach did not work but hey ho; a solution!

Thank you so much for the help; it is truly appreciated.