Is the sourcecode of riched32.dll or riched20.dll available somewhere
If not - what could I do if i want to create a richedit textfield that behaves slightly different (like changing the control for the scrollbars, such that i can change the size and positions of them from outside)
thanks
In Windows, if one wants to create a common control that behaves differently, they would create it as usual and subclass it.
Related
I setup constrains in wAny hAny size class, and it worked on iPhone & iPad simulators.
Then I switched to wAny hCompact size class and made some changes
It looks good in iPhone landscape mode, but change nothing in iPad, because iPad is wRegular hRegular. I try to apply these constrains to wRegular hAny size class, but can't find a quick way to do that. It makes no sense to manually modify all the constrains again.
I found that if I double click a constrain in Inspector panel, there's a option to install the constrain to other size classes. But this is only for a single constrain...
So, is it possible to apply all the constraints from one size class to another?
Thought i'd post this even though Hannes answer was accepted as it might be of use to somebody. You can bulk update the size classes for your constraints by editing the source code directly. Generally a bad idea to edit IB generated XML directly but I have performed an update using good old find and replace and it's saved me a lot of time.
Obvious disclaimer: make a backup of the file in case something goes horribly wrong ...
Look for the nodes like:
<variation key="heightClass=(Size Class)-widthClass=(Size Class)">
In my case I wanted to transplant all my 'Compact Width/Compact Height' constraints to 'Any Width/Compact Height', and was able to achieve this by doing a find/replace of '-widthClass=compact' with an empty string to change 'heightClass=compact-widthClass=compact' to just "heightClass=compact".
To get to source code view right click the storyboard file in xcode and select 'Open As > Source Code'
Pretty straightforward in this instance and a lot easier than doing it in IB as I had lots of constraints to update.
Select the Constrains on the left panel.(Select all the constraints). Then tap on Attribute Inspector on the right panel. Then add the class you want to add like how we add the UI elements.
Ref Image
No, you cannot edit all the constraints together.
But for each, you simply click that plus button in front of Installed and add wAny hAny and select that. Then your constraint will apply to all size classes. You can add more options and thus, decide when constraints apply.
Find and replace story board code:
I did this to migrate from compact-regular to any/any . Works for me .
Find - heightClass=regular-widthClass=compact
Replace - default
For other size clasees find the size string appropriately and resize.
Kudos!!
Update constraints at the end. Else everything would be not as expected.
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.
Is it possible to create a GWT form without manually specifying sizes of components ?
I'm looking for layout managers that work a bit like in Swing, where you can simply pack things in a panel with a proper layout manager and constraints and never care about size/width/height. However it seems like in GWT all typical layouts (eg. Dock, Horizontal/Vertical) either require size parameter or don't exist (GridBag, unless you count in very limited FlexTable).
Such layout exists in GXT, but I would recommend to use plain-old CSS + HTMLPanel. It will give you in the end the same result, but in a little bit different way.
I'm developing an application with Gtk and Glade. My impression is that it's common practice to create a subclass of GtkWindow for your main window, but I'm stuck on how I would construct my subclass from a GtkBuilder definition. Does anyone know how?
Subclassing GtkWindow is more common in GTK's various language bindings than it is in plain C. You didn't mention which language you were using.
That said, the way I subclass GtkWindow in C is to create the contents of the window in Glade, but not the window itself. In Glade 3 (IIRC) you can right-click on a widget in the palette and choose "Add widget as toplevel" to place a non-toplevel widget without a container.
Then write code for your subclass of GtkWindow, let's call it MyAppWindow. I won't go into that in this answer since there are plenty of examples in the GObject documentation. In the init function (my_app_window_init()) load the Glade file, use gtk_builder_get_object() to get a pointer to the outermost widget in the Glade file, and use gtk_container_add() to add it to the window you are constructing. Then use gtk_builder_connect_signals() as you normally would.
You have to set all the window's properties manually this way, since you can't do it in Glade, but other than that I've found it works quite well.
it is not common practice to subclass GtkWindow.
i don't think it is possible to subclass toplevel window created from gtkbuilder definition.
gtkbuilder needs to know about your subclassed widget before creation.
If you really want to create your own subclass of GtkWindow ptomato describes the basic steps well. It is also possible to create plugins for glade to make your custom widgets available. But this is not very easy, and most likely not what you want to do.
Most applications only use standard widgets without subclassing any of them. Then loading a glade file with gtkbuilder (or libglade) you don't need to have a special class for your GUI (like in some other RAD tools) instead you just get a set of objects. The API lets you look them up by name (and the window is basically just one of them). A common approach is to look up all widgets you are going to interact with and store them in global variables when the program starts up. Or if you need several instances of the window you can create a struct to store them in. Or you can simple lookup the widgets each time you need them. Note that the set of objects you get is completely dynamic. You can for example move the widgets between different windows just as if you created the GUI programmatically.
I am trying to create GTK Widget like shows in following Images
Is it possible to create it in GTK+ under C,
I tried using GtkExpander but it is not working out ...
Can any one Help....
Stripping the arrow is quite trivial. Just append the following code to you $HOME/.gtkrc-2.0 (or create it if not found):
style "pradeep" {
GtkExpander::expander-size = 0
GtkExpander::expander-spacing = 0
}
widget "*.GtkExpander" style "pradeep"
This is done by customizing the appearance using resource files. You can get the same result programmatically by changing the GtkExpander style properties.
Furthermore, you can connect your own callback to its "activate" signal and switch the background color of the widget whenever is active or not. And a lot more...
Just remember someone loves to have a consistent user interface.
If what you want is to duplicate the look, then there are two very inefficient solutions to the problem:
Write your own GTK theme engine (see Murrine or Clearlooks).
Replace your entire program by a GtkDrawingArea widget and use Cairo to draw exactly the look you want. You'll be on your own then, though, so you'll have to write all your widget placement algorithms, buttons, expanders, menus, and whatnot, from scratch.
GTK isn't really meant for this sort of thing. The whole point of GTK is that you design your user interface with the standard widgets, and they just work with whatever theme, language, or accessibility technologies your users need to use. If you design your own look and there's no way to change it, then someone with color blindness or poor eyesight won't be able to use it. Or the text will get all misaligned if someone uses your application in another language. Or at the very least, maybe someone just likes a black desktop with white lettering, and your application will stick out and look really ugly on that user's computer. If you really need to make it look exactly that way, then probably GTK isn't the right tool for you.