Why are certain classes missing from intellisense?
I like intellisense, it is handy. It is also puzzling. Certain objects are missing and I do not know if I have some setting set incorrectly or that is just "how it is."
Dim DR As DataGridViewPaintParts "This class appears.
Dim DR As DataGridViewRow 'This class does not appear, although the others do.
Dim DR As DataGridViewRowContextMenuStripNeededEventArgs 'This class also appears.
I would presume that the DataGridViewRow is more widely used than the other two, maybe I'm wrong. But in any event, why does it not appear for me?
Hans Passant actually answered the question in his comment:
Note the Common and All tabs at the bottom of the popup window. You need All to see everything. Not terribly consistent in what it filters, this feature was removed in recent VS versions.
Related
It is nice that Firemonkey got again the Hint property for controls, at least in Delphi Berlin and Seattle.
However, the implementation seems to be a bit flawed yet.
One weird issue is that the displaying of the Hint seems related to the form's BorderIcons property. If the BorderIcons are left with the default values (Maximize, Minimize, SystemMenu), the hint shows. But if I change some of the border icons, the hints don't show any more. I don't see any logic for it, so it looks like a bug. I traced some code in the FMX.Forms unit, but couldn't find any relation to the border icons. The hints in TriggerControlHint and other methods seem to be set correctly.
Has anyone had such an issue and have you solved it somehow?
There are other issue, like hints not working on a XE8 project converted to Seattle on Windows. It was mentioned in this question Firemonkey Hints don't work in Delphi Seattle, for a project converted from XE7. I fixed that by recreating the dproj file and it probably has something to do with the default manifests/themes.
Also hints for controls placed on a TLayout don't show, because the layout doesn't have the ShowHint property. Doesn't sound very logical to me, but at least it can be overcome by setting each control's ShowHint property manually.
The issue is reported on QC as RSP-13218
After more tracing through FMX.Forms I found the bug.
In the end of the TCommonCustomForm.Create method the hint object is set with
if not (csDesigning in ComponentState) then
FSharedHint := THint.CreateNewInstance(Handle);
but when the BorderIcons are changed, and also in other cases, it calls the TCommonCustomForm.Recreate method, which also recreates the window handle, so the hint is no longer linked to it.
To fix it I had to also recreate the hint by adding a few lines before the finally clause in the Recreate method:
if Visible and ([TFmxFormState.Showing] * FormState = []) then
FWinService.ShowWindow(Self);
// Added lines
if not (csDesigning in ComponentState) then
begin
FSharedHint.Free;
FSharedHint := THint.CreateNewInstance(Handle);
end;
I support an old (late 90s) Domino DB that has a growing number of Mac users. In some docs, layout regions become grayed out once you click anywhere in the doc even though it's still editable, i.e. if the cursor was in a text field and you type something blindly and save it, it will be there when you reopen the doc. It doesn't happen in all docs and I have found no pattern.
Any Domino designers seen any behavior like this? I don't this there is anything too weird in the code; onBlur or onChange used in some cases - that sort of thing. Nothing too complicated really. Thanks!
Layout regions are a nightmare to maintain: there can be objects with differing hide-when formulas stacked on top of each other that might be causing this. I suggest making a copy you can work in without worry: inspect each object fully (keeping notes) then delete. Keep drilling down until you hopefully hit an object that matches your grey-out. If you don't find one, then it could be a bug as posted by Richard Schwartz. As Richard and D.Bugger suggest, perhaps it's time to rebuild the functionality without using a layout region: layout regions never worked with a web browser.
I have recently been asked if I could make a macro in Excel VBA that will allow a user to type in two numbers and have it automatically drop to the next row. The purpose of this is so they can type in grades for a test two numbers at a time without pressing enter since they aren't great at typing.
When I first heard this he mentioned it was Visual Basic, so I figured I'd just use a TextChanging or TextChanged event in the cell range and have it work off that. However, I haven't been able to find any such event or anything resembling it in the documentation thus far. The first thing that I came across was Workbook_Change, but that only changes after you press enter which is useless to me. Someone else mentioned there is such an event, but couldn't name it directly and I haven't been able to find what they were talking about.
If anyone has any information on if such an event exists or is possible I'd love to know.
The Excel version is 2007 as far as I'm aware.
This, in my opinion, requires a non-programming solution. I absolutely sympathize - it is tough to watch people get old - but you have to draw the line somewhere - for their sake and yours. The enter key is the most basic part of a computer. You could probably write a macro that would automatically hit enter on every even(or odd depending) keystroke in excel - but you're going to run into other problems like not being able to use delete normally. And what if you do want to put a string of text in a cell(like the student's name)? Perhaps it is time to find a non-programming solution. By that I mean someone should have a candid conversation with him about how he wants to solve the problem. Personally, I would offer to type the numbers in for him, as I am accustomed to the number pad - but it is probably better to be more direct and start to discuss retirement.
See this discussion about the limitations of cell edit mode in excel:
http://www.mrexcel.com/forum/excel-questions/524860-call-macro-every-keystroke.html
If you're really heart-set on a programming solution, I would recommend some kind of keystroke logging add-in.
Good Luck.
You could use the Worksheet_SelectionChange event. It is triggered without enter, but it would be triggered a lot.
You could however also create a special user-form for typing in the data, but this might be more work than necessary.
The main problem with using my suggested event is, you will need it as trigger and trigger it yourself, when selecting the next row, so disable event handling before changing the selection.
Edit:
This is a quick solution (paste this into the vba-code of the desired worksheet):
Private Const clngColumnRightToLastGrade = 5
Private Sub Worksheet_SelectionChange(ByVal Target As Range)
If Target.Column = clngColumnRightToLastGrade Then
Application.EnableEvents = False
'offset selection, one row down, two cols to left
Target.Offset(1, -2).Select
Application.EnableEvents = True
End If
End Sub
This will set you one row down and to column C, everytime your selection changes to column E (=5).
You don't have to use a constant of course, you could specify the column to sense in the workbook, so your user might modify it easier by himself.
To make this as an optional feature, you could extend it to autogenerated code. What I have in mind is like a Ribbon-Button, which opens a setupForm to configure, and a Ribbon-Button to activate the configuration, which would place this code in the configured sheet. But this might be a bit over the top.
In Excel 2003, (may be different in Excel2007 ?!) the WorkSheet_Change event is triggered every time the value of a cell is changed wether it is by pressing enter, delete, selecting an other cell after modifying a cell or even when a vba script changes the value of a cell.
I would do something like that:
Private Sub Worksheet_Change(ByVal Target As Range)
Dim RefRange As Range
Set RefRange = Intersect(ActiveSheet.Columns("??????????"), ActiveSheet.UsedRange)
If Not Intersect(Target, RefRange) Is Nothing Then
Target.Offset(0, 1).EntireColumn.Range("A1").Select
'Target.Offset(0, 1).EntireColumn.Range("A65536").End(xlUp).Offset(1,0).Select
End If
End Sub
I'm teaching myself (read hacking) through some old Excel Macros that are quite long. However, as I change quite a few lines I want to be sure that I know when and where my new and re-hashed elements are occuring - or not. So my question/s is:
How do I insert a simple message box function that will pop up when a loop/procedure/event has finished?
Add text to it explaining what happened (hard coded ofcourse)?
Also, include an "OK button" that makes it start the next procedure?
The breakpoint process may be the most effective way of doing this, but I would like to use the message box approach so that I can show my colleagues what is happening. Also it would be something that I'd like to incorporate into future projects.
Many thanks for any examples, links or helpful hints.
Michael.
Just use
MsgBox ("message here")
And if you want to go to the code so that you can debug from there on use CTRL + BREAK
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.