I want to use an editor to display a log from a program, I just need a very basic text field:
With a vertical scrollbar
With a contextual menu for copy/paste
Prevent the user from changing the text
In order to activate the copy/paste menu, I use the class racket:text% from framework rather than the basic one.
How to prevent the user from changing the text?
I read the documentation, as far as I understand the closest thing I found is lock method:
https://docs.racket-lang.org/gui/editor___.html?q=lock#%28meth._%28%28%28lib._mred%2Fmain..rkt%29._editor~3c~25~3e%29._lock%29%29
But it is not convenient, as it also prevent my program to write the data.
I also find get-read-write? but cannot find set-read-write.
Use the lock method, and just unlock the editor around any modifications that you want to do. You may find it useful to write a call-with-unlock helper function or with-unlock macro.
If you do your updates from the eventspace's handler thread (and you probably should; use queue-callback if they originate from another thread), then as long as you re-lock the editor at the end of an update, the user will never be able to interact with the unlocked editor.
Related
I have a database that I work on using Access 2013, though I must maintain compatibility with Access 2010; I am using Windows 7.
I have an input form that is set to Pop Up = Yes, and Modal = No. When opening this input form directly from the Navigation Pane, it functions perfectly normally.
I have a macro in a search form that calls up this input form with the specified record using the "OpenForm" action. When opening the input form with this macro, the form's background is totally garbled (it pulls the background image from whatever was behind it when called, as though it were transparent), and all labels are unreadable.
That said, if I run the macro again by trying to open a different record, the form then appears correctly until it is closed. Also, if I change the "Window Mode" in the "OpenForm" action to "Dialog" rather than "Normal," it appears correctly.
Neither of these are valid solutions, though -- it should work on the first time, and I do not want the form to be modal. All my code seems okay (insomuch as I am not receiving error messages), so I don't understand why it would be doing this... any guidance is very much appreciated.
I have discovered what is causing this problem, though I don't understand why.
The macro I am using came from a sample database, and has some commands I am not fully familiar with. One such command is "Requery."
I experimented with removing various parts of the macro with the window mode as "Normal" for the "OpenForm" command. As soon as I tried removing "Requery" (and nothing else) the window opened in "Normal" mode with no distortion whatsoever.
In short, having "Requery" in the macro was what was causing this error to occur. It seems like an innocuous enough action (all it does is refresh data, from what I understand, as described here: https://msdn.microsoft.com/en-us/library/bb177360(v=office.12).aspx), but since I don't see why its inclusion was necessary anyway (if anyone could shed some light on that, it would be appreciated), it looks like this is essentially solved.
I hope this may help someone else in the future!
I'm still pretty new to scripting in Unity3D, and I'm following along with a tutorial that uses GUI.Button() to draw a button on the screen.
I am intrigued by how this function works. Looking through the documentation, the proper use of GUI.Button is to invoke the function in an if statement and put the code to be called when the button is pushed within the if statement's block.
What I want to know is, how does Unity3D "magically" delay the code in the if statement until after the button is clicked? If it was being passed in as a callback function or something, then I could understand what was going on. Perhaps Unity is using continuations under the hood to delay the execution of the code, but then I feel like it would cause code after the if statement to be executed multiple times. I just like to understand how my code is working, and this particular function continues to remain "magical" to me.
I don't know if it's the right term, but I usually refer to such system as immediate mode GUI.
how does Unity3D "magically" delay the code in the if statement until
after the button is clicked?
GUI.Button simply returns true if a click event happened inside the button bounds during last frame. Basically calling that function you are polling: every frame for every button asking the engine if an event which regards that button (screen area) is happened.
If it was being passed in as a callback function or something, then I
could understand what was going on
You are probably used to an MVC like pattern, where you pass a controller delegate that's called when an UI event is raised from the view. This is something really different.
Perhaps Unity is using continuations under the hood to delay the
execution of the code, but then I feel like it would cause code after
the if statement to be executed multiple times.
No. The function simply returns immediately and return true only if an event happened. If returns false the code after the if won't be executed at all.
Side notes:
That kind of system is hard to maintain, especially for complex structured GUI.
It has really serious performance implications (memory allocation, 1 drawcall for UI element)
Unless you are writing an editor extension or custom inspector code, I'd stay away from it. If you want to build a menu implement your own system or use an external plugin (there are several good ones NGUI, EZGUI,..).
Unity has already announced a new integrated UI System, it should be released soon.
Good question. The unity3d gui goes through several event phases, or in the documentation
Events correspond to user input (key presses, mouse actions), or are UnityGUI layout or rendering events.
For each event OnGUI is called in the scripts; so OnGUI is potentially called multiple times per frame. Event.current corresponds to "current" event inside OnGUI call."
In OnGUI you can find out which event is currently happening with >Event.current
The following events are processed link:
Types of UnityGUI input and processing events.
-MouseDown
-MouseUp,mouse button was released
-MouseMove,Mouse was moved (editor views only)
-MouseDrag,Mouse was dragged
-KeyDown, A keyboard key was pressed
-KeyUp A keyboard key was released.
-ScrollWheel The scroll wheel was moved.
-Repaint A repaint event. One is sent every frame.
-Layout A layout event.
-DragUpdated Editor only: drag & drop operation updated.
-DragPerform Editor only: drag & drop operation performed.
-DragExited Editor only: drag & drop operation exited.
-Ignore Event should be ignored.
-Used Already processed event.
-ValidateCommand Validates a special command (e.g. copy & paste).
-ExecuteCommand Execute a special command (eg. copy & paste).
-ContextClick User has right-clicked (or control-clicked on the mac).
Unity GUI has much improved lately and is quite usefull if you want to handle things programmatically. If you want to handle things visually, i recommend looking at the plugins heisenbug refers to.
If you decide to use unity gui, i recommend using only one object with ongui, and let this object handle all your gui.
GWT's Editor framework is really handy and it can not only be used for editing POJOs but also for read-only display.
However I am not entirely sure what the best practice is for doing inline edits.
Let's assume I have a PersonProxy and I have one Presenter-View pair for displaying and editing the PersonProxy. This Presenter-View should by default display the PersonProxy in read-only mode and if the user presses on a edit button it should allow the user to edit the PersonProxy object.
The solution I came up with was to create two Editors (PersonEditEditor and PersonDisplayEditor) that both added via UiBinder to the View. The PersonEditEditor contains
ValueBoxEditorDecorators and the PersonDisplayEditor contains normal Labels.
Initially I display the PersonDisplayEditor and hide PersonEditEditor.
In the View I create two RequestFactoryEditorDriver for each Editor and make it accessable from the Presenter via the View interface. I also define a setState() method in the View interface.
When the Presenter is displayed for the first time I call PersonDisplayDriver.display() and setState(DISPLAYING).
When the user clicks on the Edit button I call PersonEditDriver.edit() and setState(EDITING) from my Presenter.
setState(EDITING) will hide the PersonDisplayEditor and make the PersonEditEditor visible.
I am not sure if this is the best approach. If not what's the recommended approach for doing inline edits? What's the best way to do unit-testing on the Editors?
If you can afford developing 2 distinct views, then go with it, it gives you the most flexibility.
What we did in our app, where we couldn't afford the cost of developing and maintaining two views, was to bake the two states down into our editors, e.g. a custom component that can be either a label or a text box (in most cases, we simply set the text box to read-only and applied some styling to hide the box borders).
To detect which mode we're in, because we use RequestFactoryEditorDriver (like you do), we have our editors implement HasRequestContext: receiving a null value here means the driver's display() method was used, so we're in read-only mode. An alternative would be to use an EditorVisitor along with some HasReadOnly interface (which BTW is exactly what RequestFactoryEditorDriver does to pass the RequestContext down to HasRequestContext editors).
Yes,Presenter-View pair should be. But Here two ways to achieve this feature if you like to go with:
1) Integrate Edit/View code design in one ui.xml i.e.Edit code in EDitHorizonatlPanel and View code in ViewHorizontalPanel.The panel has different id. By using id, show/hide panel with display method. if getView().setState() ==Displaying then show ViewHorizontalPanel and if getView().setState()==Editing then show EditHorizontalPanel.
2) Instead of using labels, Use textboxes only. set Enable property is false when you need it in view mode otherwise true
You have created two Presenter/view but I think if Edit/View function has similar code so no need to rewrite similar code again and again for view purpose.
If a big project has so many Edit/View function and you will create such type of multiple View/Presenter than your project size become so huge unnecessary.
I think that whatever I have suggest that might be not good approach but a way should be find out which help to avoid code replication.
It seems for me that best place for validation of user input is in focus-out-event handler of entry type widgets (but this is only my thinking). I try to return TRUE from focus-out-event with idea that this will avoid to transfer focus to next control and keep focus on current widget, but this is not OK (not work as needed).
Which is proper way to suppress of transfering focus to next control in case when validation don't pass and where to put validation code on such widgets (gtkEntry, gtkSpinButton, etc) to be usable with signals invoked with both - mouse and keyboard actions?
That is hardly a good idea... Focus is (should be) always owned by the user. That is, the users should be able to move the focus wherever they see fit. If you try to direct the focus, or prevent moving it, based on any logic you can imagine, you will likely frustrate them.
It will surely frustrate me! Say for example that I wrote a wrong data in a box, and then I say, "hey, that's wrong! I want to select that data over there, copy it and paste it here". But I cannot do that because the program will not let me leave the box where I am now without writing an acceptable data. I have to delete the wrong data and enter something... just not good.
The best way to validate the user entry is when you actually do something with it. Either when you save it or when you make it effective. Then you can even make a pop-up saying that there is an error, and when it is close, move the focus to the first error.
If you feel that the user can benefit from an early warning that he is doing wrong, you can use colors (paint the box yellow/red if there is an error), or add a small error icon next to the box. That is waaaay less disruptive than moving the focus around.
I am trying to bring my secondary form to the Foreground, however when I do
MyForm.Show; // It may be hidden, therefore show it first
SetForegroundWindow(MyForm.Handle);
my Main Form appears aswell. The only way I can prevent that is to do MainForm.Hide; but I got to avoid that.
The idea is to have my secondary form appear on top of another application, without my Main Form having to do so as well.
If you consider to make another application for this functionality, then you may also consider the following compromise: minimize the MainForm to the taskbar (rather than hiding it) to prevent it popping up when activating another form.
If so, then try this answer. It does add an extra icon to your taskbar for the secondary form, but I guess that'll be no problem since a different application would either. However, if the MainForm is nót minimized but obfuscated by other windows, activating the secondary form wíll also popup the MainForm, just like you are experiencing now.
And for the completeness of this answer's sake, but not by any means meant as advice: this answer describes a (somewhat experimental) construction to make fully independent windows. The little time I tested that solution, it seemed to work, but be prepared not counting any longer on the full/default functionality of the VCL.
Try settings the state of the form to fsAlwaysOnTop.