IDE: c++ Builder XE5 Update 2
TeeChart: TeeChart Pro 2014.11.140512 VCL/FMX release
I utilized TeeChart's TLegendScrollBar tool for the first time recently(handy tool).
The issue I have come across:
When clicking on one of the scroll-arrows the following happens:
Single Click - The owner chart's TChart.Color property changes(background color). The original color is then restored once another event updates the chart.
Hold Down - The owner chart's TChart.Color property randomly toggles between the original color and unwanted color.
The color changes seems to happen after a TChart.OnAfterDraw call(after the intial OnAfterClick call for the Single Click case).
Example(Before and After):
Easy to replicate:
Create new VCL Forms application and add a TChart component to the form.
Add a TLegendScrollBar tool and number of series to the chart(chart editor).
Set the TChart.Legend.MaxNumRows property to a value smaller than TChart.SeriesCount().
Run.
Questions:
Is there a entry point(s) after TChart.OnAfterDraw wherein I could attempt to rectify the issue? Or a workaround?
(if not 1) Is there a way to completely remove(hide and disable) the scroll arrows?(force the user to use either the mouse-wheel or scroll-thumb to scroll the legend)
I could reproduce the problem so I've added it to the public tracker: B979
You can follow the ticket to get automatic notifications when an update arrives.
Related
What is the name of event when we start drawing the markup(circle, arrow, rectangle etc.) on the shape when in edit mode? And can we change the markup type in this event?
Problem is: When we are in edit mode and have selected specific shape and color to draw the markup, and in between if we select any markup, the drawing tool takes up that shape and color for the next markup to be drawn ignoring the markup type and color we selected earlier. Is this the normal behavior. Why does the drawing tool take up the configuration of the last selected markup and overrides the type we define through - new Autodesk.Viewing.Extensions.Markups.Core.EditModeCloud(markupExt);
Thanks!
That's an interesting question. I believe the current behavior of markups is as-designed because one would typically only select a markup if they wanted to move it around, scale it, etc. That's why in the current implementation, selecting a markup automatically enters its edit mode.
At the same time I understand your view where if I already activate a specific edit mode, it seems strange that that edit mode would change after simply selecting another markup.
Let me bring this up with the engineering team, and in the meantime, I'd suggest using the Autodesk.Viewing.Extensions.Markups.Core.EVENT_EDITMODE_CHANGED event to detect a change to the edit mode, and if needed, reset the mode to the one you want.
When I double-click on an animator controller to launch it, the animator tab appears, but when I run the editor, I don't get the usual flow, operations, etc... I only get a static view of the states and transition arrows between them. My parameters do not show the changes they go through either.
I have multiple animations and can switch between them when certain game conditions occur, but nothing really shows when I do so, to see the flow of control, what happens, what goes wrong, the switching, the progress bar, etc...
I have the latest Unity 5.2.0f3 so I wondered if it is just me or others are having a similar problem...
What we need to do is this: Once we hit the play in the editor mode (and have the animator window docked on one side, of course) we just go and click the object in the hierarchy for which we want to analyse the animation flow. And the animator window will start showing the states and the progress bar.
Also, after upgrading to Unity 5.2, it is worth checking the values that were previously set for transition states, for example if vSpeed is greater than 0.1 then start walking. All my set values were messed up; i.e. changed.
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'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.
I am working in Visual Studio 2005. I have multiple splitters on the screen. I have set the splitters IsFixed and I have also set fixed panel sizes. In addition to this I have locked the control. For some reason, when I switch into debug mode the splitter distance value is changing entirely on its own. These changes do not take place with any consistency, the vary in distance changed. Other components, which are also locked, are moving all on their own as well.
Anyone with similar experience? Any ideas?
The settings will stick to either mode you are in. But sometimes plugins or parts of VS does mess it up :(
I recall seeing a plugin written to save 'views', but when I tried it, it didnt work.
I couldn't tell you what is causing this. The way that the windows forms splitter works is through the Docking property. There should be no need to lock the controls. All of the controls on the form should be docked. (Including the splitter)
For example, if you want to split vertically, you have your first panel docked left. Then the splitter (Orientation set to vertical) is also docked to the left. The second panel is docked to fill. The width of the first panel (which is docked left) will determine the location of the splitter. It should not change now.
The z-order is important here for layout purposes. If you want a more detailed look of how the controls are laid on on your form, open the Document Outline. This will list the controls in a tree, and you can see where they are in the z-order.