After moving and rearranging controls on a Winform when invoking a Build and/or Rebuild All command the following error message appears :
"An error occurred while processing this command. Could not load file
or assembly 'LoLock, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=null' or one of its dependencies. The system cannot
find the file specified."
At that point all the controls disappear from the Designer and form the executing form as well. I've scoured the designer cs file and run diffs against a previous working version and cannot find anything amiss.
This has happened to me on several occasions and appears to be random.
Any clues ??
I've had the same problem...exactly...same error followed by the disappearance of most of the controls. The controls that are missing in the designer are my custom controls. The change I made before the error and the disappearance was to add a constructor to each of the controls derived class (i.e. my part of the control). So far, I've noted that the Control.Add(...) is missing for each of the hundred or so controls that have disappeared (from the automatically generated Form.designer.cs file). This is the one point that seems to differ from your situation if you are running a diff on the designer.cs file between pre and post failure. Mine definitely has missing Add()s.
So far, my solution is to manually add back the Add() methods to the generated file. However, it would obviously help if there was some way to get visual studio to see this problem and add the controls back automatically. However, I can't think of any way that VS could know, at this point, which controls to add to which parent control.
For example, before the error I had the following group box defined in my designer.cs file:
//
// groupBox10
//
this.groupBox10.Controls.Add(this.checkBox_FincaDescription_ForRent);
this.groupBox10.Controls.Add(this.checkBox_FincaDescription_ForSale);
this.groupBox10.Location = new System.Drawing.Point(883, 67);
this.groupBox10.Name = "groupBox10";
this.groupBox10.Size = new System.Drawing.Size(310, 76);
this.groupBox10.TabIndex = 9;
this.groupBox10.TabStop = false;
this.groupBox10.Text = "Property Type";
After the FAIL I have the following code which was generated as a result of either the error or simply the designers failure to manage my custom controls:
//
// groupBox10
//
this.groupBox10.Location = new System.Drawing.Point(883, 67);
this.groupBox10.Name = "groupBox10";
this.groupBox10.Size = new System.Drawing.Size(310, 76);
this.groupBox10.TabIndex = 9;
this.groupBox10.TabStop = false;
this.groupBox10.Text = "Property Type";
This is a massive FAIL for me as I have so many fields to manually correct (although luckily only a few group boxes and a good backup). I have read of so many people having this same problem from 2005 on, I can't believe it hasn't been addressed.
I also experienced this with a user control.
I received an exception for each control that had the Add method removed from the designer.
Surprisingly, I had a couple of panels, and the Add code for the children of those panels remained in tact.
I only had to implement Add for those panels and a few controls that were not in containers, which is fortunate because there were over 100 controls.
An error was introduced in the constructor of the user control, and I believe that this contributed to the chain of events resulting in the corrupt designer file.
Related
For the last few days i have been trying to figure out the best way to get AutomationElement for a specific control in a vb6 application.
My initial way of doing so was by doing a search with the following condition:
new PropertyCondition(AutomationElement.NameProperty, controlName)
I was under the assumption that this was working correctly for about a week in a little test VB6 application.
but i few days ago i realized something... when i dragged a vb6 textbox into the form, the 'Name' property and 'Text' property were both set to 'Text1'
So when i searched with:
new PropertyCondition(AutomationElement.NameProperty, 'Text1')
it return the correct element, but if i then went and set the 'Text' property to '' the same search would bring nothing back.
Question: Has anyone found a way to get a AutomationElement based on a the VB6 control name
What i have tried:
getting the MSAA equivalent interface and looking at the 'Name' property - Result: ''
http://msdn.microsoft.com/en-us/library/windows/desktop/dd318490%28v=vs.85%29.aspx
getting the control based on other properties (AutomationId, RuntimeId) - Result: AutomationId - not all controls seem to have this property available - RuntimeId - changes each time the app runs
I have looked at alot of different sites the main one is listed below - while some say they have manage to get it working - i don't believe i can see how they do it.. or i just dont understand it :$
http://blogs.msdn.com/b/brianmcm/archive/2006/01/17/getting-the-winforms-id-of-a-control.aspx
While i have access to the demo app, i will not access to the production app as that has been created by a third party.
What i plan on doing from here is to get the Automation element based on their position on the form..
Thank you
Can't comment due to low rep. Do you absolutely HAVE to have an AutomationElement?
You may want to look at invoking [user32.dll] (http://pinvoke.net/default.aspx/user32.EnumChildWindows). Look at FindWindowEx, GetWindow, EnumWindows, EnumChildWindows, GetWindowText, etc.
You need the handle of the parent window, so you can use this loop to get it. From there you can use the other functions to get the information you need about the control.
IntPtr hWnd = IntPtr.Zero;
foreach(var process in System.Diagnostics.Process.GetProcesses())
if(condition)
hWnd = process.Handle;
Comment with the exact information you need out of the VB6 window, and I'll give you better code.
You can use the relational position of the AutomationElement in a specific Window (or any other container for that matter), in order to detect it. For example, if you have 5 TextBox AutomationElements in your main window, and you're certain that the order will not be changing, you could create a PropertyCondition on the TextBox class name, and then use the FindAll method to return a collection of AutomationElements and iterate through it, querying the BoundingRectangle property to find out which is the lowest one (or middle, or any other position, for that matter).
I would create a helper method that would return a Dictionary<int,AutomationElement> with the key being the visual position of the AutomationElement, and the value being the AutomationElement itself.
This way you can avoid using a specific Point on your screen (any window size change or element positioning will easily break your code) while not being bound to the AutomationId property.
I have started to automate my windows application using coded UI tests recently and facing issue while accessing some of the MSAA control.
I am hand coding my automation and do not want to add controls to UI Map and then use it.
The control on which I got stuck is a treeItem on a left pane which selects machine and details are displayed in left over client area at the center.
I have tried to search control using properties as shown by crosshair onto the UI control but in vain.
Below is the code I have tried -
UITestControl machine = new UITestControl(App);
machine.TechnologyName = "MSAA";
machine.SearchProperties.Add(WinTreeItem.PropertyNames.ControlType, "TreeItem");
machine.SearchProperties.Add(WinTreeItem.PropertyNames.Name, "Machine1");
machine.SearchProperties.Add(WinTreeItem.PropertyNames.ControlName, "m_tvPlantStructureView");
Mouse.Click(machine); // This code gives an error
ERROR-
Microsoft.VisualStudio.TestTools.UITest.Extension.UITestControlNotFoundException:
The playback failed to find the control with the given search
properties. Additional Details: TechnologyName: 'MSAA' ControlType:
'TreeItem' Name: 'Machine1' ControlName: 'm_tvPlantStructureView'
---> System.Runtime.InteropServices.COMException: Error HRESULT E_FAIL has been returned from a call to a COM component.
Refer to attachments.
Let me know, what is the problem and what process to follow to completely get away of such kind of errors of controls not recognized in future.
Currently, I follow the method of doing a crosshair and getting properties and then coding on that property of control to automate user actions and assertions. But this way does not always work.
Let me know if there is any better way of doing it.
You need to do a hierarchy search. Create 2 controls: first the Treeview as Window. With control name m_tvPlantStructureView, then create a new TreeItem with name Machine1.
var treeView = new WinWindow(App);
treeView.SearchProperties.Add(WinWindow.PropertyNames.ControlName, "m_tvPlantStructureView");
var machine= new WinTreeItem(treeView);
machine.SearchProperties.Add(WinTreeItem.PropertyNames.Name, "Machine1");
Mouse.Click(machine); // This code gives an error
Another thing if this fails is to remove App from treeview and add window title.
Let me know if you have any questions.
var treeView = new WinWindow();
treeView.WindowTitles.Add("mywindowname");
treeView.SearchProperties.Add(WinWindow.PropertyNames.ControlName, "m_tvPlantStructureView");
var machine= new WinTreeItem(treeView);
machine.SearchProperties.Add(WinTreeItem.PropertyNames.Name, "Machine1");
Mouse.Click(machine); // This code gives an error
Before doing the mouse clik, I perform a search of the control using
machine.Find();
After that, I check if machine has a value distinct of null, and if is it not null, i perform the click.
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.
I am trying to use ultimate grid from Code Project in a dialog box but the grid is invisible.
m_Plist.AttachGrid(this, IDC_CREDENTIALS) returns true but the static text place holder where the grid should be shown cant be seen and the grid is never displayed.
I am using sample the code from here http://www.codeproject.com/KB/MFC/UltimateGrid_Start.aspx?display=PrintAll&fid=452565&df=90&mpp=25&noise=3&sort=Position&view=Quick&select=2629959&fr=51#Using_the_Grid_in_a_CDialog
I have installed the latest update UltimateGrid72_Src_Update03.zip and Im using VS2008 SP1.
Thanks...
BOOL CCredentials::OnInitDialog()
{
CDialog::OnInitDialog();
MyCug m_PList;
m_Plist.AttachGrid(this, IDC_CREDENTIALS);
}
I've not used Ultimate Grid myself. However, looking at the code you posted, I can see that there is likely to be a problem: you declare an instance of "MyCug" on the stack, then attach it, but that stack-based instance will be destroyed as soon as the OnInitDialog() method exists. What you must do is put the declaration of "MyCug m_PList;" as a member of the dialog class, so that the lifetime of the grid object is the same as the lifetime of the dialog.
I don't know why your grid is not displaying, things to look for are is it correctly loading from the dialog template, and is it visible? You can use spy++ (a tool distributed with visual studio) to see what windows are actually created in your dialog, where they are and the flags and styles set on them.
After you create and attach the grid, are you adding rows and columns as defined by the examples?
Otherwise, there isn't going to be anything to see.
You'll need the following code in MyCug::OnSetup():
void MyCug::OnSetup(){
//*******Set the Rows and Columns
SetNumberCols(10);
SetNumberRows(10);
}
That's from the tutorial in the 7.2 version. I used UG extensively, and have no problems with VS2008. But I create all my grid myself, I don't use dialog templates.
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!)