[Gambas-user] Clearing data from TextAreas & ListBoxes
Rolf-Werner Eilert
eilert-sprachen at ...221...
Tue Mar 3 10:34:54 CET 2015
Am 03.03.2015 10:11, schrieb John Rose:
> On 03/03/15 08:31, Fabien Bodard wrote:
>
>> And thé controls Will not be cleared until the procedure is not ended.
>>
>> Use an ascyncronous call to your external program can help you.
>>
>> You can use a timer trigger too that delay the call to the next event loop
>> Le 2 mars 2015 21:35, "Tobias Boege" <taboege at ...626...> a écrit :
>>
>>> On Mon, 02 Mar 2015, John Rose wrote:
>>>> On 02/03/15 19:25, Tobias Boege wrote:
>>>>> On Mon, 02 Mar 2015, John Rose wrote:
>>>>>> I have a Click event on a Button. At runtime, clicking the button
>>> should
>>>>>> cause clearing of the data from a TextArea & some ListBoxes. There's
>>> no
>>>>>> way this 'clearance' cannot be executed as the Exec of a CL program
>>>>>> (which definitely happens because it populates these controls) soon
>>>>>> follows it. However, it doesn't seem to do so. Clearance coding:
>>>>>> With StopListBox
>>>>>> .Clear
>>>>>> .Refresh
>>>>>> End With
>>>>>> With SteckersListBox
>>>>>> .Clear
>>>>>> .Refresh
>>>>>> End With
>>>>>> With ReflectorListBox
>>>>>> .Clear
>>>>>> .Refresh
>>>>>> End With
>>>>>> With RotorsListBox
>>>>>> .Clear
>>>>>> .Refresh
>>>>>> End With
>>>>>> With DetailTextArea
>>>>>> .Clear
>>>>>> .Refresh
>>>>>> End With
>>>>>>
>>>>>> Is the above the correct method of causing the clearance to happen on
>>>>>> the screen immediately?
>>>>>>
>>>>> That last word is important. Controls are refreshed during the event
>>> loop
>>>>> which you can think of as the pause mode of the interpreter: it enters
>>> it
>>>>> when there is no Gambas code to execute at present. The interpreter
>>> sits
>>>>> there waiting for events to happen or does maintenance like redrawing
>>> the
>>>>> GUI.
>>>>>
>>>>> You can force the interpreter to look at pending events (and to redraw
>>> the
>>>>> controls by the way!) by using the Wait instruction without argument.
>>>>> Calling Refresh() is not necessary here which saves you 3 lines per
>>> Clear()
>>>>> call.
>>>>>
>>>> Tobi,
>>>>
>>>> I changed coding to:
>>>> Public Sub RunButton_Click()
>>>> ...
>>>> StopListBox.Clear
>>>> SteckersListBox.Clear
>>>> ReflectorListBox.Clear
>>>> RotorsListBox.Clear
>>>> DetailTextArea.Clear
>>>> Wait
>>> Here, the controls are cleared.
>>>
>>>> ...
>>>> aExecParameters = ["/opt/Enigma/turing_bombe_all_wheels", sMenuPath]
>>>> 'sMenuPath points to an input file
>>>> pturing_bombe = Exec aExecParameters Wait For Read As
>>> "TuringBombeResultsDetail"
>>>> ...
>>>> PopulateListBoxesFromDetailsTextArea
>>>> ...
>>> Here, they are filled again with data from the external process.
>>>
>>>> End
>>>>
>>>> Public Sub TuringBombeResultsDetail_Read()
>>>> Dim sLine As String
>>>> Line Input #Last, sLine
>>>> Print "SO=" & sLine
>>>> DetailTextArea.Text &= sLine & "\n"
>>>> Wait
>>>> End
>>>>
>>>> It still did not clear the displayed contents of those controls. I
>>>> clicked the button once (i.e. when the contents were already clear) and
>>>> it populated the above controls as expected. I clicked the button again
>>>> but it did not clear the DetailTextArea or the ListBoxes immediately.
>>>> The CL program took a few seconds to run and interestingly when it
>>>> finished it did not add to the controls' contents (i.e. it cleared them
>>>> before populating them again).
>>>>
>>> Yes, that's precisely what the code above is meant to do, right? First you
>>> clear all the controls, then you start an external process to fill them
>>> anew. If you don't want to refill the controls, don't start the external
>>> process which gives you the new data.
>>>
>>> In case I'm misunderstanding here, the best practice seems to me to be:
>>>
>>> [ 0. don't top-post, ]
>>> 1. send a *small* project which shows your problem (with one or two
>>> controls to clear and a call to "ls" or something),
>>> 2. tell me exactly what you want to achieve
>>>
>>> and I'll send you the corrected project, if I can accomplish it.
>>>
>>> Regards,
>>> Tobi
>>>
>>> --
>>> "There's an old saying: Don't change anything... ever!" -- Mr. Monk
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Dive into the World of Parallel Programming The Go Parallel Website,
>>> sponsored
>>> by Intel and developed in partnership with Slashdot Media, is your hub for
>>> all
>>> things parallel software development, from weekly thought leadership blogs
>>> to
>>> news, videos, case studies, tutorials and more. Take a look and join the
>>> conversation now. http://goparallel.sourceforge.net/
>>> _______________________________________________
>>> Gambas-user mailing list
>>> Gambas-user at lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/gambas-user
>>>
>> ------------------------------------------------------------------------------
>> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
>> by Intel and developed in partnership with Slashdot Media, is your hub for all
>> things parallel software development, from weekly thought leadership blogs to
>> news, videos, case studies, tutorials and more. Take a look and join the
>> conversation now. http://goparallel.sourceforge.net/
>> _______________________________________________
>> Gambas-user mailing list
>> Gambas-user at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/gambas-user
> Tobi & Fabien,
>
> Bottom posting as requested. Project named Test attached: stripped down
> from original project. I want the DetailTextArea to be cleared
> onscreenimmediately when a second or subsequent Run is done (i.e. the
> Run button is clicked twice). When the Run button is clicked it causes
> the execution of 2 CL programs: create_menu & turing_bombe_all_wheels -
> the second one taking 10+ seconds to execute. Currently the
> DetailTextArea is only cleared onscreen when the turing_bombe_all_wheels
> has finished executing.
>
> I have attached a tar.gz of the command line C programs. the tar.gz
> should be extracted, the CL programs compiled (by cd to the extracted
> directory, 'make clean all TARGET=linux' & 'make all Target=linux
> VERBOSE=3', the create_menu & turing_bombe_all_wheels programs copied to
> a new /opt/Enigma/ directory, and the Test Gambas app run (after
> extraction etc from the attached tar.gz of it), I have attached a Crib
> file containing two 12-character lines: AFRHSQESERKG and IEDSIEGFRIED.
> The first set of 12 characters is to go into the left hand 12 Cyphered
> MaskBoxes & the second set of 12 characters is to go into the left hand
> 12 Plain MaskBoxes. When you run the Test Gambas app, either type in the
> above 2 sets of 12 characters or use the appropriate Paste buttons to
> paste them from the clipboard.
>
> Fabien,
>
> You say "And thé controls Will not be cleared until the procedure is not ended.Use an ascyncronous call to your external program can help you.". In Gambas, how do make an asynchronous call to an external program? I do not want to amend the coding in the external program turing_bombe_all_wheels. Current coding:
> pturing_bombe = Exec ["/opt/Enigma/turing_bombe_all_wheels", sMenuPath] Wait For Read As "TuringBombeResultsDetail"
>
From my experience: Once I tried to build a small window showing some
text during printing. The window appeared, but never the text. Until I
inserted some WAITs at the most lengthy loops, but since then printing
is somewhat slower. There is a Cancel button as well, but it never
canceled anything, printing will be over until the process loop gets it.
There is some comfort: Other programs show this problem as well, it is a
matter of GUI handling.
The only thing that would really help is stopping all program activity
for a moment so the GUI has a chance to redraw everything. WAIT is your
best chance here.
Rolf
More information about the User
mailing list