_GUICtrlCreateInput

[feeks]

Hi I am a long-time AutoIT looker that has finally dipped my toes and have come across an issue that appears strange on _GUICtrlCreateInput. This may be because I have not read enough documentation or it may be a bug and hoping that I can get some assistance.

I am attempting to create an Input field that obtains a microsoft style account in the form DOMAIN\accountname and what I am finding is that if I enter the \ character as the separator nothing is returned to the field on GUICtrlRead, regardless of whether I default the text field to a known account name or enter an account as text in the required form. If I change the form of the separator to say a - as in DOMAIN-accountname then the input field returns the expected content.

Any assistance would be appreciated

Edited September 29, 2009 by feeks

[smashly]

Hi,

Post a brief working snippet of code that shows your problem please.

You'll probably get quicker assistance from others if they have a little code to work with.

Cheers

[feeks]

Hi,

Post a brief working snippet of code that shows your problem please.

You'll probably get quicker assistance from others if they have a little code to work with.

Cheers

Sorry ... forgot the obvious

Here is the definition of the Control

$Input1 = GUICtrlCreateInput("TRN\Administrator", 16, 56, 121, 21)

GUICtrlSetTip(-1, "Administrative Domain\Account to process request")

GUICtrlSetOnEvent(-1, "Input1Change")

and here is the control read:-

$accountCredentials = GUICtrlRead($Input1,0)

I realise that I can split the domain and the account and rejoin the but was wanting a single read to run the back-end with either workstation or domain in a domain environment hence the "DOMAIN\accountname" form this however does not generate an error but simply does not return anything. If I conver the data to say "DOMAIN-accountname" the control read returns the data as entered!!!

Once again thank you for any assistance that can be provided

[feeks]

I have been playing a bit further and there does appear to be an anomally with the input control. If I run the process multiple times I can get the control read to work regardless of what characters I have put into the control with the exception of the initial read. Characters that I have tried as separators are . - [ * \

I am running the script from with Scite. I will compile the environment and see if this makes any difference.

[Zedna]

For me everything works fine.

#include <GUIConstantsEx.au3>

GUICreate("Test", 320, 120) 
$input = GUICtrlCreateInput("a\b", 10, 10, 300, 20)
$btn = GUICtrlCreateButton("Test", 40, 75, 60, 20)
GUISetState()

$msg = 0
While $msg <> $GUI_EVENT_CLOSE
 $msg = GUIGetMsg()
 Select
    Case $msg = $btn
        MsgBox(4096, "Result", GUICtrlRead($input))
 EndSelect
WEnd

[feeks]

Thanks Zedna

The code as provided works with the only difference being I am using Opt("GUIOnEventMode", 1) with associated control events. Are there any known timing issues with collecting data via events as it appears that the issue is only on the primary read of the controls, if I make secondary edits to the input fields the correct data is returned as expected and as per your sample. I have had this happen in multiple environments (work and home)?

[Zedna]

Post whole (but simple) reproducing script.

[feeks]

Post whole (but simple) reproducing script.

Zedna

I have been able to get this to work by performing a priming read to all controls on the form at start-up. If you comment out the call to the function primingread() this is when I get problems with the data being returned from an initial state. If I do not perform the primingread() the only way that I have been able to get the expected returned data is to update the data particularly in the input fields at least 2 times to the extent that I have highlighted the domain\accountname separator and replaced it with itself which really makes no sense to me.

Edited October 1, 2009 by feeks

[smashly]

Zedna

I have been able to get this to work by performing a priming read to all controls on the form at start-up. If you comment out the call to the function primingread() this is when I get problems with the data being returned from an initial state. If I do not perform the primingread() the only way that I have been able to get the expected returned data is to update the data particularly in the input fields at least 2 times to the extent that I have highlighted the domain\accountname separator and replaced it with itself which really makes no sense to me.

Hi again,

Hey feeks, I'm aware your new to the forums and I'm sorry to be an ass, but..

"POST A BRIEF WORKING EXAMPLE SHOWING YOUR PROBLEM"

Describing your problem isn't going to make it any easier or resolve your issue and it becomes just as frustrating to the ppl trying to help as your problem is to you.

The reason I say this is input fields work fine with "\" when using GUICtrlRead(), regardless if your using OnEvent or not.

So it only leaves some other bit of your code that is causing the issue.

Post a brief working snippet of code that shows the problem happening, this way your issue will be resolved a lot quicker and save ppl trying to guess why your getting your problem.

Cheers

[feeks]

Hi again,

Hey feeks, I'm aware your new to the forums and I'm sorry to be an ass, but..

"POST A BRIEF WORKING EXAMPLE SHOWING YOUR PROBLEM"

Describing your problem isn't going to make it any easier or resolve your issue and it becomes just as frustrating to the ppl trying to help as your problem is to you.

The reason I say this is input fields work fine with "\" when using GUICtrlRead(), regardless if your using OnEvent or not.

So it only leaves some other bit of your code that is causing the issue.

Post a brief working snippet of code that shows the problem happening, this way your issue will be resolved a lot quicker and save ppl trying to guess why your getting your problem.

Cheers

My bad ... forgot to attach the app. This has now been amended

[smashly]

Hi,

Just curious as to why in 2 instances (line 134, line 235) your using:

$accountCredentials = GUICtrlRead($Input1,1); the ,1 is not used for reading input controls

Maybe try it as:

$accountCredentials = GUICtrlRead($Input1)

That's about the only thing I can suggest ftm.

Cheers

Edited September 30, 2009 by smashly

[feeks]

Hi,

Just curious as to why in 2 instances (line 134, line 235) your using:

$accountCredentials = GUICtrlRead($Input1,1); the ,1 is not used for reading input controls

Maybe try it as:

$accountCredentials = GUICtrlRead($Input1)

That's about the only thing I can suggest ftm.

Cheers

Hi and thanks smashly. I can't recall why I tried the ,1 argument on

GUICtrlRead($Input?)

! it now appears that the issue is not an inability to deal with the \ data but one of not picking up the default value of the Text field defined in each control or the default selection in the combo controls and date fields.

I have attached 3 pictures showing various stages of data entry effect which demonstrates what I see as inconsistent with my reading of the command and the use of the "Text content" field and the example provided by Zedna which works in my environment.

In noprimingread.png I have disabled the primingread() and directly performed the "Process Accounts Request" action without making a change to any control values and get no "Text content" from any control on the form which I presumed to be the equivalent of the default field value returned on GUICtrlRead.

In noprimingread-editedinput.png I edited some of the fields, in the same processing session as noprimingread.png, namely the 2 input controls and one of the combo controls which are then returned on GUICtrlRead but no unchanged control text field value is returned. This is where I see a difference in what was achieved with the example provided by Zedna and what is being returned via this GUICtrlRead.

In the third primingreadneabled.png I have forced an initial primingread() of all the controls on the form which has the dual advantage of populating the status bar with current control Text Field values but also populates the fields into the output of the "Process Accounts Request" call which meets the desired outcome but I view this as an extra step in the process.

Am I barking up the wrong tree? Or should all of the control Text field values including dates and default combo box text be returned on the first issue of GUICtrlRead as in the Zedna example/experience?

Edited October 1, 2009 by feeks

[Zedna]

I still see no system problem also with this test script converted to OnEvent mode:

#include <GUIConstantsEx.au3>
Opt("GUIOnEventMode", 1)

GUICreate("Test", 320, 120) 
GUISetOnEvent($GUI_EVENT_CLOSE, "OnClose")
$input = GUICtrlCreateInput("a\b", 10, 10, 300, 20)
GUICtrlCreateButton("Test", 40, 75, 60, 20)
GUICtrlSetOnEvent(-1, "OnButtonclick")
GUISetState()

While 1
    Sleep(100)
WEnd

Func OnClose()
    Exit
EndFunc

Func OnButtonclick()
       MsgBox(4096, "Result", GUICtrlRead($input))
EndFunc

Edited September 30, 2009 by Zedna

[feeks]

I still see no system problem also with this test script converted to OnEvent mode:

#include <GUIConstantsEx.au3>
Opt("GUIOnEventMode", 1)

GUICreate("Test", 320, 120) 
GUISetOnEvent($GUI_EVENT_CLOSE, "OnClose")
$input = GUICtrlCreateInput("a\b", 10, 10, 300, 20)
GUICtrlCreateButton("Test", 40, 75, 60, 20)
GUICtrlSetOnEvent(-1, "OnButtonclick")
GUISetState()

While 1
    Sleep(100)
WEnd

Func OnClose()
    Exit
EndFunc

Func OnButtonclick()
       MsgBox(4096, "Result", GUICtrlRead($input))
EndFunc

Thanks Zedna, I have tested this code and it works as expected however this is not the same result that I get with my code. Could I ask that you try the code submitted with the changes as defined in the previous message to smashley, in your environment to see if you get the same results that I do here?

[Zedna]

Thanks Zedna, I have tested this code and it works as expected however this is not the same result that I get with my code. Could I ask that you try the code submitted with the changes as defined in the previous message to smashley, in your environment to see if you get the same results that I do here?

Your script is overcomplicated for me.

I recommend you to do eliminating method to find source of problems:

Step by step remove unnecessary pieces of your code and test if it still has your bug.

This way you can quite simply find it yourself without any low level knowledges.

[feeks]

I have followed your recommendation by decomposing and simplifying the GUI and it would appear that the issue is not with the input control but in the order in which the data entry is performed.

What I am finding is that if I jump straight to either input control the GUICtrlRead() for that control seems to be ignored, (no data is returned), however if I start data entry from any control prior to the input control the GUICtrlRead() is performed as expected.

I have tested this with both current version and current beta release and the response is consistent. Is this a known issue or should I be looking elsewhere?