I have some memory leaking. I am creating a big object graph and then derefencing it.
var a = MyDomainModel.Create();
a = null;
//GC.Collect();
Console.ReadLine();
There is no unmanaged stuff in there. JustTrace and ANTS (version 6) are both reporting that the objects are held in place by "System.Object[]".
I am assuming that there is a static field (list/dictionary/hashset) hidden somewhere that is using an ArrayList internally. I am planning to do a bit of text searching (probably some regex in there, too).
It is a pretty big solution with 30 projects. Is there any way I can do Visual Studio text search in "current project and all projects within the solution that are referenced directly/indirectly by current project"? The underlying physical file folders are not organized in a way that would meaningfully represent these dependencies.
if you're using Windows 7, create a library and add your project locations to the library. that should get them all organized in one place without actually moving or copying anything. then from Visual Studio do a text search in the library folder.
I assume issue has already been solved. If anyone else is experiencing something similar, JustTrace now handles this scenario through the Root Path view. Here are several paths to it.
Largest Memory Retainers: Find one of the objects being held in memory by object[]. Select the object, then click the Root Paths button in the ribbon.
By Type: select the type then click the Instances button in the ribbon. Select one of the instances, then click Root Paths.
Incoming References by Type: select the type, then click the Instances button in the ribbon. Select one of the instances, then click Root Paths.
The root paths graph shows the member name holding the instance and marks fields/properties that are static. See the image below for an example.
Related
So I'm writing a script to modify quickly a VB6 application's interface with COM controls. (Created in C# .net). Most of it works fine, but some panels are giving me a lot of trouble.
Basically, I open the .frm file and read it, and when I find some controls I modify their values or insert new things. When I find a panel, I create a different panel around it so it looks better. I'll put, say Top = 2340 in the file for my new element. If I open the .frm in notepad, I can clearly see that the value of Top is at 2340. Once I open VB6, the panel's top value is at Top = 8190. It also modifies the Left value, but nothing else. If I save and exit vb6, then reopen the .frm in notepad, the Top value will be saved at 8190.
Why does VB6 uses different values than the ones in the .frm file? Is it trying to avoid elements stacking on top of each other ? What is happening between reading the file and opening it, that forces a different value of the Top property?
Just a theory, but I believe the issue is that the ScaleMode property isn't setup right. By default, unless the container window has the property, it'll be set to Twips. So what may be valid under certain containers won't be valid in other containers.
The MDIForm container, for example, forces Twips, and may even re-position objects based on alignment.
If this is the form itself, which I don't think it is but worth mentioning, make sure the StartUpPosition is properly set to 0 (Manual).
I have a C++/CLI project which has a child form with some control components. I would like to copy all the control components with their codes on a new Tab control on the main form. How can I do that?
You can select all of the controls in the designer (hold down the Shift key to make multiple selections), and then cut and paste them to their new location: Ctrl+X, Ctrl+V
Alternatively, you can open up the *.Designer file that is generated automatically by the Windows Forms designer and copy the relevant lines of code out of that file into your other code file. Look for the code that creates and sets properties on the controls you're interested in. For every property of the control that you have set to its non-default value in the designer, there will be a line for it in this file.
If, instead of moving (cutting) the controls from one place to another, you want to copy the controls so that they appear in multiple places, I strongly suggest creating a UserControl that contains all of the child controls and encapsulates the relevant code. Then, you can just drop an instance of this custom UserControl out of your toolbox into whatever form you want, or even dynamically create instances at runtime. This is consistent with the general programming/design principle that you should seek to keep code duplication to a minimum while encapsulating as much as possible.
We have an in house button control, and quite frankly it sucks. I'd like to replace it but I don't want to go onto every form in our project and delete/add a new control. It seems to me that if I design a new button that has all the same properties as the old one then I ought to be able to give it the same name as the old one and just replace all the reference lines in the vbp files to point to the new control.
Has anyone tried this (better yet have you heard of a tool that will do it for you) and if so what 'gotchas' should I be on the look out for?
Thanks!
The *.vbp files are one place you'll need to change. There are also references to the used control libraries in the files containing GUIs -- that's form (*.frm), control (*.ctl), and property page (*.pag) files. These files are in a plain text format and you can see the references at the top. They look like this:
Object = "{831FDD16-0C5C-11D2-A9FC-0000F8754DA1}#2.0#0"; "mscomctl.ocx"
Those refs will need to be added or updated in all relevant files if the new control is a compiled OCX. If it's in the same project I don't think it needs any reference there, and if it's in a different project in the same project group I'm not sure. Save a test form with the new control to see.
Note that you don't have to keep the same control class name. Inside the *.frm/ctl/pag files, instances of individual controls on them are represented by a simple format like this:
Begin VB.CommandButton Command2
Caption = "Cancel"
Height = 375
Left = 2460
TabIndex = 1
Top = 2400
Width = 1455
End
The syntax of the first line there is "Begin LibraryOrProjectName.ClassName NameOfThisInstance". So, provided the offending control's name is distinctive it should be easy to search & replace references to it both in the BASIC source and in the GUI layouts. You might want a plain text editor that can perform search and replace across multiple files (Notepad++ is one).
Some control properties are stored like this:
Picture = "frmMain.frx":292F
These correspond to the *.frx, *.ctx, and *.pgx files, which contain binary data for the values of certain control properties. I don't think these files should need altering or cause any problems. They don't appear to contain control names.
Use a full compile (Ctrl+F5) to be sure no problems linger in parts of the source afterward.
Never tried it. Good luck.
There is only one tip to be added to the accepted answer.
If you need to replace any generic VB control with 3rd party or custom ActiveX control you must replace the:
BeginProperty Font
with
BeginProperty Font {0BE35203-8F91-11CE-9DE3-00AA004BB851}
Omiting to do so results with run-time error 713 when trying to edit/open the form.
If there is no BeginProperty statement in the block then control uses default font and this replacement is not needed.
An additional scenario to look for is if the classes in the OCX are referenced directly in code.
In other words, if the control class was ABCButton then you need to look for ABCButton in all .BAS and .CLS files as well, and make appropriate changes.
How can I change the order of the entries in the context menu?(e.g. for Directories) I need to know how Windows determines the order when showing that so I can control it. For example I want to place my custom action at the end of the context menu list
Thank in advance!
My Google-fu led me to this:
So the sorting is based on the following elements in decision order:
Key priority (eg, txtfile, *, AFSO)
Registry Enumeration order of shellex\contextmenuhandlers with a special case for static verbs always being first
IContextMenu Implementation order
So if there is any contention for position, there is no consistent way for an extension to guarantee their relative position within the menu.
Obviously you can't do anything about phase 1. Phase 3 only applies to the verbs implemented in your handler. That leaves phase 2. The only thing you can do is name your entry under ContextMenuHandlers such that it would be enumerated first, but nothing's stopping someone else from doing the same thing.
This is for Windows 7, maybe same for newer versions. It was inspired by the other answers, all is affecting the order.
I'm explaining entries for "*" (all files), but the same goes for special extensions.
I take no responsibility for any changes made in registry!
There are three sections in the context menu, as it says in How to Change the Order of Options in Context Menu (from answer by #Anonymouse)
They call them:
2 - Default menu position (at the top).
1 - Send to, copy to folder and move to folder menu part (in the middle).
0 - Rename menu part (at the bottom).
Within these sections the position is decided by the rules in answer by #Luke
The easiest way to change the order within the "section" is to change the name of the registry key under HKCR-*-shell or HKCR-*-shellex. All under subkey shell will be before them under shellex. Keys that have the CLSID as the key name will be as last entry since they are last in the used order.
As an example, I was following a sample from MSDN to build a Context Menu Handler
EDIT 2021-04-14:
The MSDN link is no longer valid, it redirects to a "Browse code samples" page. You can search there for Context menu sample, but the one I followed seems to have been removed.
The closest to the old one I followed is perhaps this
The one I followed is using the CLSID as the name for the key under shellex, and a "friendly name" as default value. It was placed at the bottom of "section" 2 (top section). I changed the key name to something like Asample and changed the default value to be the CLSID instead. Now it was directly after entries under shell.
There are some more ways of changing the order.
For keys under shell you can add the value Position with string data Top or Bottom. Not possible to decide in what "section".
For keys under shellex the value Position has no effect. Instead it's possible to decide in what "section" the entry will be using flags, described in the link above.
Use the CLSID for the shellext you want to move. It's like
{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}. Get it either from the key name or the default value, it depends on how the entry is done.
Find the entry under HKCR-CLSID, the key has the name of the CLSID.
Add a value with name flags and data DWORD with the "section" number described above under the found CLSID.
This did it for me... Steps 4 through 7 - setting the "flags"
http://techoqueries.blogspot.de/2012/08/how-to-change-order-of-options-in.html
This Q&A shows a simple way to CREATE (not move) an item within the context menu. I managed to duplicate an existing item. Then I moved my item to a higher and more accessible position within the context menu, by renaming the key to start with something "aMyItem" or "0MyItem".
I've been trying to find a way to re-order things, it irritates me that the daily use options are pushed to the end, when obscure utilities you might use once in a blue moon are filling up the top of the list.
I found a lazy way to do this, using a little utility package called "Windows 10 Manager" Windows 10 Manager - it's a few quid, but it's a lot easier than registry hacking. It can't do everything, but it does let you add items into the top section at least - and also to suppress cheeky ones that installed themselves in there without asking.
As you can see, it's actually duplicated some entries rather than moving them, but never mind.
My project has maybe 130 controls (total of all labels, textboxes, etc.) in an SSTab (4 tabs). The project loads fine, it runs fine, I don't see a single error or warning at any point, but when I save the form with the SStab on it, the SStab data isn't saved (it is completely gone). Normally the relevant portion of the .frm file looks like this:
Begin TabDlg.SSTab SSTab1
Height = 8895
[1550 more lines of code for all the controls]
Width = 540
End
Begin VB.Menu FileMenu
But lately it's getting cropped to:
Begin TabDlg.SSTab SSTab1
Begin VB.Menu FileMenu
This is very frustrating! In my VB IDE, the frame, sstab, and all the controls are there, editable, running/compiling fine, no error messages at any point, but when you save the file, 1550 lines of precious sstab data just disappears - again, with no warning or error messages. So if you exit and restart the IDE, you get a form load error because 60% of the code is now missing. The log file points to the first error it finds (in this case a Begin TabDlg with no End) - there's no other info in it. (The log file was generated after the code was deleted and saved, so it makes sense that it wouldn't be helpful.)
When I first posted this question, I thought it had to do with the number of controls, because it appeared after I added a control, and in my first few tests, seemed to disappear when that control (or other controls) was deleted. Now I can't seem to get that form to save under any circumstances, even when I delete many controls (bringing the number of controls far below where it was when it was last stable).
I also tried deleting the SStab and moving all the controls to 4 different frames. I successfully did that in the IDE, but when I saved, a huge chunk of the data (starting with a slider control) was missing. So I have no fraking idea what is going on.
The problem is reproducible on two different PCs, so it doesn't appear to be a hardware/corrupt software VB install issue.
Has anyone else run into something like this?
Create a UserControl for each tab. That makes editing MUCH easier. It also allows you to nicely modularize the code, so each tab lives in its own file, and it'll allow you to reuse tabs elsewhere if you want.
Sounds horrible, never heard of anything like that.
Presumably you aren't getting an error log file from VB6 when you load the form into the IDE before it gets corrupted? The log file has the same filename as the form file but with a .log filename extension. For example, if errors occurred when loading Myform.frm, Visual Basic would create a log file named Myform.log. The error messages you might see there are documented in the manual.
Have a look in the Windows Event Log, see whether it records any interesting problems against the VB6 IDE?
Are you using any weird controls? Maybe one of them is somehow corrupting the FRM or FRX. FRM files are just text as you obviously know & the format is documented in the VB6 manual. Can you see any corruption in the FRM in a text editor? If you remove any properties defined in the FRX, does it still fail.
I think I would try creating a new project and a new form, and then use the IDE to copy and paste all the control definitions into it - no code. Play with the new form, see whether it has the same problem. Maybe you can recreate the form this way without the problem. If the new form does have the problem, do the same thing but only take half the controls. Maybe you can find a problem control by "binary search".
I get the same problem when attempting to save a form when the .FRM is writable but the .FRX is read-only
Not sure if this is the issue, but on a VB6 form, there is a limit to 255 (or is it 256) named controls. Perhaps you are running into that?
One way around that limitation is to use control arrays. For example, if you had 10 labels, instead of label1, label2, label3, etc, you could do label(0) through label(9), and use up only one named control.
The other thing worth mentioning about the SSTAB is the way it shows/hides controls. While it may appear that the controls are on separate tabs, what is really happening is that the controls are getting moved waaaayyyyy to the left (and consequently out of view). Perhaps with so many components, the SSTAB is choking on this in the IDE as it tries to render the controls in design view?
Again, not sure if this is the issue, but I know these two tidbits are relatively unknown.
So the SAVE function is not working.
I suspect one of the components you are placing on the tab strip is the culprit.
So ..
1) Take an inventory of each and every kind of component you are placing on the form
2) eliminate one (kind), SAVE
3) Did it SAVE?
-> Yes = that was the problematic control
-> No = return to step 2, but pick another kind
Of course, its important to remove all controls of a certain kind in step #2 (for example, ALL labels, or ALL textboxes, etc).
I have never heard of this happening however.
You are not alone! I've seen this problem. . .in fact I'm dealing it right now, which is what brought me to this site.
I've been working with VB since '94 (VB3) and I first saw this problem about 5 or 6 years ago, while using VB6. My solution then, was not unlike some of the suggestions that you have recieved from the good folks who've responded above: throw out the existing file and rebuild the form in a new file. I did that back and the affected form has worked ever since.
My current problem is appearing in another, much newer form, and the replace/rebuild option (performed about a month ago) only worked for about three weeks. Now the problem is back and each new iteration of the file gets corrupted very quickly. Following the reply above regarding the total number of allowable controls, I'm looking into just how many controls I have. . .and, as it happens, I was in the process of consolidating the primary the buttons and menus into control arrays, simply because it was going to streamline their management.
I can also confirm your observations about moving the project to a second PC. . . I've done that too, and problem persists. Moreover, I can add that I have moved the project from one shared storage system to another to no avail. (The original storage location was on a drive mounted to a Win-tel system and the new location is on a UNIX-based NAS!)
Just rebuilt the file again and checked: Controls.Count = 62, so I am no where near the 255 control limit mentioned previously. This is indeed strange! (Not to mention furstrating!)