lonewolf32

With our latest release we are starting to install shared assemblies into the GAC, which in itself is no big deal. However, we do have a problem for which I did find a solution, but the solution might not be very attractive or even viable for Vista. A while back we added methods to a Logger class that accept a stack frame number to obtain file name and line number information, and many of our C# component use these methods. Internally the Logger class makes use of the .NET StackTrace class which in turn relies on the corresponding PDB, which must be in the same folder as the assembly. And all this works perfectly. Now we've got our assemblies in the GAC, which means we also have to copy our PDB's into the GAC, which is probably quite problematic, but I don't know what else to do except pulling the stack frame based Logger methods. That would mean that we would lose line number information. Any ideas?

Wouldn't that violate rules in Vista about writing in the Program Files directory? Secondly, we could "roll our own" and create a similar structure under the "All Users" directory or something, but the question is whether that is advisable, or if we need to do it in the first place. Thanks!

subscribing...

My company is finally moving to Visual Studio 2008 for development. We have been developing .NET applications for a while now but have never settled the issue of whether we should still be using the Registry to store settings. Currently I am making use of user.settings to store user type things. But what should we do if we want to have common settings that several applications that exist in different directories (i.e. different products) need access to? Should we continue to utilize the Registry or is there some accepted way of sharing settings? I just remember hearing things about the Registry going away in the future, so I want to plan accordingly if that is the case. (I know this wouldn't happen any time soon, but if it is going to happen someday then we want to make intelligent choices now, while we are already shaking things up. Thanks! Dave

I figured out how to determine the width of the vertical scroll bar in the datagrid view (using SystemInformation namespace) but I found no clue as to how to determine if it is displayed or not (i.e. do I have enough rows in my dgv to cause it to be displayed). I am computing column widths during the resize event of the dgv but the fact that the vertical scroll bar is present or not present comes into play. Does any one know how to tell if the vertical scroll bar is displayed in a datagridview? Thanks.

I am having trouble figuring out the right way to deal with column widths in a datagridview. I'll post 2 screenshots to help illustrate. The reason I am having trouble is that my grid is completely customizable in regards to which columns are displayed. The user can choose to only look at the 3 required columns, or they can look at 4, 5, 6, 7, or the full 8 columns if desired. I do not want to use the Fill setting on the grid globally because then the columns never gets wider then the width of the grid. I do not want that because they couldn't see all the useful info. I do not want all that "whitespace" on the right, however, when a smaller number of columns are selected, just because (am I right on this?) it looks unprofessional. So basically I would like to see that whatever columns are selected for display, are at least as wide as the grid control, but also can be wider. Thanks for any input.

Yes, I should have clarified -- all of our users are admin level users so writing to Program Files shouldn't be a problem. I have to admit though, going forward, questioning the admin status of users on Vista. All of our users for XP and lower are admin because we tell them its required. In our app you just can't get anything done without admin access. But with Vista's better UAC - that may have to change. Something to think about. Thanks!

Hi folks - I have a number of questions regarding app and user settings in Visual Studio 2005. - I see that app.settings is stored with the EXE and user.settings is stored under the user's home directory. I also see that app.settings values are unchangeable at runtime. I realize this is to comply with Windows logo requirements, but I would like to have settings that are changeable at runtime, stored with the EXE. Is this at all possible? - Is System.Configuration namespace the one that was used in VS2003 (deprecated)? This namespace provides a way to access a app.config file directly, so I am assuming this is the case. If I am creating an application should I avoid this namespace? Basically I am looking for a way to remove Registry dependency from my current application. Currently my registry settings are under HKLM (not HKCU) so the settings need to be app-level (not user-level) and they need to be modified at runtime. Thanks!

I tried this, and yes both datagridviews resize accordingly - but how do I get the arrow buttons in between them? I tried putting them in one of the split panes along with the data grid control, but the dgv just moves over my buttons when the app is resized (see attached). Thanks!

Can someone help me figure out how to set my anchors and dock settings on this form? I have tried several combinations but nothing produces the desired effect. I am using C# and Visual Studio 2005, with standard controls. The grids are DataGridViews. What I want to see happen, is when the user resizes the form, the 2 grids always stay the same size as each other (growing OR shrinking, both vertically and horizontally), and the arrow buttons always stay between the two grids. I want the edges of the grids to stay on the form (not disappear off of the edge when shrunk) - this is easy with the vertical aspect using anchors, but the horizontal aspect is a real pain. At least, I haven't figured it out yet. This would mean that the right grid's Location would be changing as the user resizes, and the buttons Location (they are on a Panel) would be changing, and both grids dimensions would be changing at the same time. Nothing I have tried so far has produced the effect of keeping the grids the same size as each other. Plus, usually the right grid moves left and goes over the top of the buttons and over the top of the left grid. I even tried putting each in its own Panel, but so luck so far. Any help is greatly appreciated. Thanks!

Re: My .NET form goes behind others after COM goes away I have a .NET form written in C# (VS2005 SP1) that instantiates a COM object. That COM object brings up a VB6 form. When I close the VB6 form, my .NET form disappears behind any other forms that happen to be open such as Windows Explorer windows for example. I have to click its icon on the taskbar in order for in to come back to the front. EDIT: It appears that its not that the form is going behind, but that the window where the task was launched is brought forward, and given focus. If I run from the debugger, VS2005 gets the focus, and if I run the EXE from a Windows Explorer, then WE gets the focus. I have already tried this.BringToFront(); Is there a way to keep my .NET form in the foreground? Thanks!

This method seems to have done the trick. Other then having to remove the "static" key word from the ThreadProc declaration (can't use "this" in static method), it worked just as written. I tried it in both situations, and they appear to be working now with no draw problems. Thanks!!!! Here is the final code. private delegate void WorkCompletedHandler(); private void WorkCompleted() { //Peform final processing Singleton.Instance.InitLogging(); Singleton.Instance.LogFlow("Returning from COM app"); //Enable the form this.Enabled = true; } private void btnMEU_Click(object sender, EventArgs e) { Singleton.Instance.LogFlow("Starting COM app"); Singleton.Instance.TermLogging(); // Queue the task. ThreadPool.QueueUserWorkItem(new WaitCallback(ThreadProc)); this.Enabled = false; } private void ThreadProc(object state) { ModelExtractorUtility.Launcher meu = new ModelExtractorUtility.Launcher(); meu.ApplicationID = Singleton.Instance.ApplicationID; meu.LogCfgFile = Singleton.Instance.LogCfgFile; meu.WorkingDirectory = Singleton.Instance.WorkingDirectory; meu.Launch(); this.Invoke(new WorkCompletedHandler(WorkCompleted)); }

We may have to scratch that theory completely - I just tried bringing up another VB6 COM form, and this time the distortion appears on my COM form! Note the weird black boxes. (see attachment) This form shows up fine when I open it from a VB6 project. Here is the code that brings up that COM object (it is included as a Reference obviously): private void btnMEU_Click(object sender, EventArgs e) { ModelExtractorUtility.Launcher meu = new ModelExtractorUtility.Launcher(); meu.ApplicationID = Singleton.Instance.ApplicationID; meu.LogCfgFile = Singleton.Instance.LogCfgFile; meu.WorkingDirectory = Singleton.Instance.WorkingDirectory; meu.Launch(); } Could this still be a threading issue?

I am trying to implement this threading suggestion. I got it halfway working (the thread starts and the form distortion is gone) - but I need the originating thread to stop working until my VB6 thread is done. I am trying to implement a Mutex, but I am having no success. Here is the code, what am I doing wrong? (Note that I tried both ThreadPool.QueueUserWorkItem, and a simple Thread.Start) private static Mutex mut = new Mutex(); private void btnMEU_Click(object sender, EventArgs e) { // Queue the task. //ThreadPool.QueueUserWorkItem(new WaitCallback(ThreadProc)); Thread myThread = new Thread(new ThreadStart(ThreadProc)); myThread.Start(); // Allow new thread to start and claim mutex Thread.Sleep(1000); // Now wait for the mutex to be released mut.WaitOne(); } // This thread procedure performs the task. private static void ThreadProc() { // Claim the mutex so the originating thread has to wait mut.WaitOne(); // Do my work // Release the mutex mut.ReleaseMutex(); }

Just wanted to add a follow-up comment. This only happens when I put up a VB6 form in front of it. If I put up another .NET form this does not occur. But I still have the problem as I do not want to rewrite my VB6 code yet. Thanks.