Can't update textview instantly - monodevelop

I've a text view and a method has a while loop does things among them appending to text view
But The text only changes when the method ends.. (but the console shows changes instantly
How to update it instantly??

You have to give the UI, i.e., the gtk code, the chance to update the pixels on the screen. The update happens when your method exits because that is when gtk gets back in charge and can do the changes. If you want to do a lot of work and still update the UI just execute the work in a separate thread and update the UI by calling Gtk.Application.Invoke() from time to time.

Related

How can I subscribe only once to the app-db in re-frame?

I need to subscribe to the app-db for a value that I want to check only once when the parent component is rendered. For example, when I click a button "Click me", and there's a certain on-click event being processed, whose status I have saved on the app-db with the list of processes that are being done, I just want to check against that value once, and display two different components based on that value.
If the value is empty, I want to proceed with the normal event. If not, I'd like to show something else to the user, a popup for example.
Now the thing is that, because it's actively listening to the app-db, and the value is changing almost every second (or in a matter of milliseconds), the said popup appears, disappears, reappears, and disappears again super fast with each change to the app-db, which isn't helpful at all.
I would like to just subscribe once, get the value, and do the checks based on the value when the parent was first rendered. And then I'll do something to make that go away.
If I click the "Click me" button once again, that's only when I'd like for it to re-render.
I haven't quite been able to achieve this. I tried numerous methods such as introducing a delay during the dispatch of popup as well as after introducing processing states to the app-db in the first place hoping that since the data will already be in a steady state, it might not change as much, but now that I realize it's actively listening to it, it's expected that the values would change.
I did try using the subscription without the deref, but that only introduced an error to my frontend, so I'm not sure which way to go now.
My error with the component diappearing/reappearing turned out to be triggered by something else. A conflict/mismatch with popup-ids and a dispatch to clear one popup leading to destroying all of them.
But to answer the question, it works when you introduce a (fn []) block after the let binding where you actually do the subscription, and calling the components from inside the fn.

Submitting batch UI update actions

I'm writing a minesweeper clone using Seesaw. For the minefield, I'm using a simple grid-panel of buttons. I've gotten to the point where when you click on a button, it will flood fill the grid to uncover all the empty tiles surrounding where you clicked. To "uncover the tile", I'm just disabling the button associated with the tile.
The problem is, it's uncovering incrementally, even though the task being executed isn't that expensive. It will update a few spotty buttons around the grid randomly over time, and it looks really bad. I would rather have a second of lag than for it to disable the buttons procedurally.
This is basically the button click handler:
(doseq [b buttons] ; Buttons are the grid cells
(let [[tx ty] (sc/user-data b) ; The cell position is stored in the user data
tile (b/get-tile-at board tx ty)] ; O(1) lookup
(when (:uncovered? tile)
(sc/invoke-later ; Because this chunk is actually being executed in a pool
(sc/config! b :enabled? false)))))
Since there's nothing expensive going on here, it seems like each config! call makes a change to a button, and the button's appearances are updated as the changes happen.
Is there a way to have every call to config!/button update happen all at once, even if it creates a small amount of perceived lag?
I'm not familiar with seesaw or its internals, but you want to find a way to use double buffering in Swing.
See also:
https://docs.oracle.com/javase/tutorial/extra/fullscreen/doublebuf.html

What is the purpose of widgetPerformUpdateWithCompletionHandler in iOS 8 Today Widget?

Been looking around for an answer but everything seems vague or unclear.
Anyways, just want to know what the purpose of the function:
widgetPerformUpdateWithCompletionHandler
does in the today widget.
According to Apple:
This method is called to give a widget an opportunity to update its
contents and redraw its view prior to an operation such as a snapshot.
When the widget is finished updating its contents (and redrawing, if
necessary), the widget should call the completion handler block,
passing the appropriate NCUpdateResult value.
When does the snapshot ever happen? Whenever I debug the extension, widgetPerformUpdateWithCompletionHandler always gets called after loadView. So what is the purpose of explicitly reloading information in this method when I already load the information in loadView?
According to this website: http://www.karlmonaghan.com/tag/today-widget/
In the TodayViewController, there are two places that need to load
data from the network – when the widget is created and when
widgetPerformUpdateWithCompletionHandler is called. For the former, I
load posts in viewDidLoad, so that they should be ready by the time
the widget displays. When iOS thinks the widget will be displayed to
the user after it has been first displayed,
widgetPerformUpdateWithCompletionHandler is called giving the widget a
chance to update the posts displayed.
Same question as above.
A widget is not created every time you view the notification center so loadView won't be called every time it is displayed. The notification center instead calls widgetPerformUpdateWithCompletionHandler when it thinks the widget information needs to be updated. From my own debugging it does look like that when the widget is initially created widgetPerformUpdateWithCompletionHandler is called nearly straight away so you could just do all the loading in there but Apple recommends you start the loading process as early in the life cycle as possible.
If the information your widget displays never changes, then you don't have to do anything in widgetPerformUpdateWithCompletionHandler.

flex validation invalidation (component life cycle)

I am still confused with Validation and Invalidation of the component in Flex. Could anybody please give me simple comparison about what Validation can do which invalidation cant and vice versa.
I really appreciate your any help.
Thanks.
Although I do agree with the comments, this is pretty well documented I think your just missing the overall relationship between "invalidation" and "validation" methods. Basically whenever you're making a call to invalidate somethings, whether it's the display list, the size, or the properties then all your doing is telling it to set a boolean flag for one of those (any time you modify a property that will modify any of these three it will call the appropriate invalidate method such as invalidateProperties when set width is called). When the next enter frame/render happens, it will check the flags and if any of them are set to invalid it calls the corresponding validation method (updateDisplayList, commitProperties, measure).
To see the code for yourself in FB/Eclipse hit Ctrl+Shift+T and pull up UIComponent, hit Ctrl+O once UIComponent.as is opened and type in validateNow you can see the method body is 1 line and there's a nice ASDoc comment there explaining what it does. Better yet you'll see it calls validateClient on a ILayoutManager, pop open LayoutManager (Ctrl+Shift+T again) look at validateClient, it explains basically what I do here.
I think this is where you're coming from because I was in that boat once too, not understanding the relationship between updating a property and it affecting it's siblings/parent/children but it's really key to reducing processing load since a property can be modified multiple times between frame refreshes and it doesn't need to re-calculate everything around it until it will actual be redrawn.
The problem being that sometimes you want to modify a property and immediately (that is on the next lines execution) be able to see how it's side affects have modified other parts of the layout, in this case you can call validateNow() after modifying a property forcing it to immediately update all of that even if it may happen multiple times before a redraw occurs. This is generally not a great practice since it usually means undesired cpu time is wasted, but sometimes it's the easiest option.

Access 97 VBA writing code

I found that I can write code just by typing everything or activate element, then click for example OnClick property and write code to between the sub-end sub lines.
One person I met said that one has always use mouse and select the property in which you want to write the code, as it might write something else to some files such that the code won't work.
Is this correct or are those two ways to write code equally good? I'm using Access 97.
The short answer is you CAN do it that way. But it doesn't mean you SHOULD.
With a little experimentation I've found that you can type in event subs directly in the code window, and their creation will be reflected in the properties window. This might not have always been the case in older versions of MS Access.
You can also create them by selecting the Control in the code window's top left pull down, and then selecting the event in the top right pull down.
Why would I choose to use the Code Builder (or at least the second option I provided). Because it prevents you from making mistakes. Both in the name of the control/event and in accidentally creating duplicate Subs. Both of which could be frustrating when debugging your application - how long could you spend looking for a bug because you added an extra "S" to an element name by accident. If you follow through from the properties window, you are guaranteed to be working on the right Sub and that it will be spelled correctly.
Note: I've also found that you can delete the entry in the properties window, but it leaves the code behind in the code window. So to make sure it is really gone, you do have to go into the code window and delete the Sub there.
That's not to say that I never do anything directly in the Code window like that - if I've renamed a control, I'll often update the name in the code window. But then I'll go back through the properties window to verify that I've re-connected the subs properly.
"Look, I'm running with scissors!"