I have a big annoying problem with auto layout sheet, if I try to change some value, width, click on standard or change from equal to less o bigger than the outlet was disabled, than if I want to modify the outlet I have to reselect e do the modific...this is very annoyng, some solution?
Not really a solution, but getting used to the appropriate keyboard shortcuts makes the workflow a little bit faster.
Cmd-Alt 4 shows the Attribute Inspector.
Cmd-Alt 5 shows the Size Inspector.
My solution was to start creating my views and windows programmatically. Auto Layout makes creating controls in code much more compelling.
The Interface Builder user interface is a train wreck with Auto Layout. It takes forever to get things set up correctly. Often changing unrelated items shifts items you were done with, restarting the cycle of fixing things.. again.
Auto Layout removes the need to use frames and sizes when creating controls in code. It used to be that creating controls in code were hard to size and place appropriately. Now it's a breeze using auto layout format strings
Creating controls programmatically allows you to do a cleaner MVC.
Creating controls programmatically makes refactoring easier. Instead of typing strings into Interface Builder for your object properties, you can use constants.
Related
I am working on a specific size class layout of an xcode project and I hit a snag.
My constraints got very messed up and I want to restart the view.
Is there a way in the interface builder for me to reset a size class (e.g wAny hCompact) back to its any constraints settings? (i.e. back to how it was with wAny hAny)
This should really be an automatic process in Interface Builder, but as far as I know it is not so you have to do the dirty work.
The best solution I have found is a combination of using Interface Builder and the source editor for this task. Remember that there are two things to reset, both the auto-layout constraints as you are referring to, but also the variations you might have created. Lets start with auto-layout constraints, and deal with variations later:
Reseting auto-layout constraints
Find a constraint you want to reset. Choose the "Show Size Selector" panel in the utilities view. At the bottom you will see the size classes this constrain has been added to. If it is only installed on the size class you want to reset, you can delete the whole constraint, otherwise, just delete it from the size class you want to reset by clicking the cross.
Variations
I have only managed to reset variations using the source editor. Either use an external editor, or "Open As -> Source Code", and search for variation elements. Make sure the size class key is correct, and delete at will.
Found a quick fix for this.
In the Storyboard go to the file inspector tab, then, under "Interface Builder Document" Section, uncheck the "Use Size Classes" checkbox and it will ask you to keep either iPhone or iPad current layout.
After choosing it, you can check "Use Size Classes" again and the other size classes will reset to the one you chose before.
Note: All other size classes will reset to the chosen class!
I'm building an application to generate an array of colors based on a color chosen by the user.
The default on Mac OS X for color selection is to open a NSColorPanel containing multiple NSColorPickers. But, as the color selection process is the main interaction the user will have with the app, it'd be better to avoid the extra clicks and panel-popping in favor of a more straightforward way.
So, is there any way to add a NSColorPicker object to a window?
I know this is an older question, but check out NSColorWell. From the docs:
NSColorWell is an NSControl for selecting and displaying a single color value.
Interresting Question.
I strongly doubt it (but would love to be proven wrong). NSColorPickers are not NSControls (nor NSCells) so there's no clean wrapper to insert into a window.
Even if you were to instanciate an NSColorPanel and get a reference to its contentView and copy it (with all that defines the color picking controls) to your own window... there's no obvious way of obtaining the color value. NSColorPickers are plug-ins so you can't forsee the controls of a colorPicker.
The only other way I can see (and that's a stretch) would be to manually load the NSColorPickers plug-ins directly. I don't know how successfull this would be.
File a bug report and request the feature?
I am working with flex for the last two years on some desktop apps. Until now I never had any performance related issues but today as we completed a mobile application for the iPad, I'm facing a challenge, the application is incredibly slow on the iPad.
http://i.stack.imgur.com/qkbWn.png
Slow, means that when I press a button in the menu to change the splitview I must wait something like 5s. Then scrolling is really slow two, with less than one fps and my TextInput starts to bug (the text is not in his box anymore).
I started to read a lot of blog post and presentation about optimisation for the mobile platform and then I rewrite some of the components I use. I removed the SkinnableContainer for instance and replaced it by a VGroup including some actionScript based drawing.
Now what you see is a VGroup (the dark grey one) containing some others VGroup (the group with title here) and then each widget is an HGroup with a label and a Widget. I only use Label and TextInput for the text.
Creation time is slow even (several seconds to create the view) for another page where there is only 4 text widget on it, or another one with only a list with a custom item renderer where each row is a set of 4 labels.
The whole things is cabled with RobotLegs, with nothing fancy, one models is injected in the view and at the beginning I set a member variable on the view with this object to bind my variables.
Frankly my thinking right now is : it smells fishy because if I've done everything right it is impossible to have such low performance and thinks that flex is competitive on the mobile platform. So right now I'm trying to disable the application piece by piece to try to locate what could slow it like that. I've got a couple suspects to check, for instance I've got some binding warning to check, and then see if robotlegs has got its share of the problem.
So my main question here is what do you think, and could you have some ideas about "is there a problem" and "how do we solve it".
Thanks
Run profiler for startup and separatelly for each operation that takes longed that it needs. Then prioritize the problems and try to solve them with basic optimization techniques.
Some problems you will not be able to solve fast - e.g. time for creating big components. The only option there is to rewrite those components with AS3 without MXML, styles and anything. I'm sure that flash.text.TextField is created many times faster than mx.controls.Label. The same for other components.
When component is created, it can be reused at a very low price. In your app there must be a lot of places where you recreate while you can reuse old components. It will save you memory and time.
Layouts tend to redraw even when it's not needed. If you have a lot of nested layouts, find the most critical places and replace a series of layouts with one custom layout or even component.
This all is very developer time consuming. At the end you will not get a smooth app anyway, but I believe that it can become usable.
In my opinion, ListPicker list items are unacceptably small tap targets; certainly their height is smaller than the minimum size recommended by the style guide Microsoft published, and fact that Microsoft has taken to presenting the list full-screen in a much larger font suggests that I am not alone in holding this opinion.
I would like to use this full-screen big-font presentation in my own UI designs. I have tried specifying a DataTemplate (as a static resource) but it didn't seem to have any effect, although I'm pretty sure it is processed because when I made a typo in the resource name the compiler complained.
On what basis do you say that the item tap target size is too small? Is this personal opinion or based on user feedback?
If you don't like default style of the ListPicker then retemplate it.
You can use the ItemCountThreshold property to control whether FullMode is always used or not (set it to 0).
You can also apply a full mode template to increase the touoch target size of what is displayed there.
I was using ListPickerItem objects for the items. This works until there are enough items to trigger Full mode and then it barfs.
If I import the System namespace and use String objects, everything's hunky dory. Supplying a DataTemplate and binding to something also works.
I think I have found a bona fide bug, but one with a trivial workaround: don't use ListPickerItem.
I'm running into a problem trying to anchor a textbox to a form on all 4 sides. I added a textbox to a form and set the Multiline property to True and the Anchor property to Left, Right, Up, and Down so that the textbox will expand and shrink with the form at run time. I also have a few other controls above and below the textbox.
The anchoring works correctly in Visual Studio 2005 (i.e. I can resize the form and have the controls expand and shrink as expected), but when I run the project, the bottom of the textbox is extended to the bottom of the form, behind the other controls that would normally appear beneath it. This problem occurs when the form loads, before any resizing is attempted. The anchoring of the textbox is correct for the top, left, and right sides; only the bottom is malfunctioning.
Has anybody heard of this and if so, were you able to find a solution?
Thanks!
UPDATE:
Here is some of the designer code as per Greg D's request (I am only including the stuff that had to do with the textbox itself, not the other controls):
Friend WithEvents txtRecommendationText1 As System.Windows.Forms.TextBox
<System.Diagnostics.DebuggerStepThrough()> _
Private Sub InitializeComponent()
Me.txtRecommendationText1 = New System.Windows.Forms.TextBox
' ...snip...
'txtRecommendationText1
Me.txtRecommendationText1.Anchor = CType((((System.Windows.Forms.AnchorStyles.Top Or System.Windows.Forms.AnchorStyles.Bottom) _
Or System.Windows.Forms.AnchorStyles.Left) _
Or System.Windows.Forms.AnchorStyles.Right), System.Windows.Forms.AnchorStyles)
Me.txtRecommendationText1.Location = New System.Drawing.Point(4, 127)
Me.txtRecommendationText1.Multiline = True
Me.txtRecommendationText1.Name = "txtRecommendationText1"
Me.txtRecommendationText1.Size = New System.Drawing.Size(223, 149)
Me.txtRecommendationText1.TabIndex = 10
End Sub
ANOTHER UPDATE:
The textbox I originally posted about was not inherited from a baseclass form (although it was added to a custom User Control class; I probably should have mentioned that earlier), but I recently ran into the same problem on a totally unrelated set of controls that were inherited from a baseclass form. It's easy to blame these problems on possible bugs in the .NET framework, but it's really starting to look that way to me.
Is your Form localized? Check the resource files for an entry with Textbox.Size, delete is and reset the size.
Is your Form inherited and is the Textbox on the baseform? Try setting the Textbox's access modifier to Protected or Public.
Have you implemented custom resize logic? Turn it off and see if the problem is still there.
Have you entered a Textbox.MinimumSize/MaximumSize? Remove or change the value.
It might also be a combination of these things...
Does the form snap back to the expected layout when you resize it after it's been initialized weirdly? Also, have you set a Height or MinimumHeight/MaximumHeight property for the text box?
If possible, a few snippets from the designer code might be useful. :)
One possibility that I've run into in the past is DPI. If you're running/testing your code on a machine with a different DPI setting than the machine that you're developing on, you may observe some strange things.
The anchor functionality essentially establishes a fixed distance between the edge of a control and the edge of the control's parent. Is your textbox embedded within another control (e.g., a panel) that doesn't have its anchors properly set? Right clicking on the text box in the designer should pop up a menu that lets you select any controls that exist underneath it, also.
Does your program include any custom resize logic, or does it modify the size of the textbox programmatically outside of designer-generated code? That might also result in weird behavior. I've assumed maintenance for a number of pieces of software at my organization where the original developers spent a great deal of time implementing (buggy) resize logic that I had to tear out so that I could just let the designer-generated code do the work for me.
The textbox I originally posted about was not inherited from a baseclass form (although it was added to a custom User Control class; I probably should have mentioned that earlier), but I recently ran into the same problem on a totally unrelated set of controls that were inherited from a baseclass form. It's easy to blame these problems on possible bugs in the .NET framework, but it's really starting to look that way to me.
It's very likely because of the 'AutoScaleMode' property being set in InitializeComponent(). Try setting it to 'None' and see if that fixes it. I've had these problem a couple of times now.