|
Not for the executing assembly, once the assemblies compiled these attributes are 'baked' in. However, you may be able to do it for a dynamically generated assembly using the Reflection Emit functionality.
|
|
|
|
|
I dont get, why would you like to do this runtime???
With great code, comes great complexity, so keep it simple stupid... 
|
|
|
|
|
Hi Paw, thanks for reply.
Ok, I have the assembly attribute
[assembly: InternalsVisibleTo("UI Test")]
And I want it applicable only when I do debugging and testing. I dont want to make internals visible to some assembly in my production build. Now, Yes, I can comment this line everytime I make a RELEASE build and comment out when I do debugging, but it is not easy to maintain. Many times I can forget to comment this line and ship the release build with this attribute. Now, if I know how I can do it programmatically, then, I will use
#if (DEBUG)
...
[assembly: InternalsVisibleTo("UI Test")]
#end if
So, I dont have to remember to comment this line.
Thats why I need the snippet for doing so. Can you give me any idea for doing this task in some other way ?
Thanks again.
|
|
|
|
|
Does # if DEBUG not work for that?
Maybe have two versions of AssemblyInfo.cs?
|
|
|
|
|
Owee... yes, it is working. I could not think that it will work, I thought I cannot write any C# code in AssemblyInfo.cs file. So, I did not dare to try. Now it see it works  thanks.
|
|
|
|
|
There isn't anything special about AssemblyInfo.cs
The file extension is .cs which stands for C-sharp.
and you can move all of its content to another C# file, e.g. Program.cs
|
|
|
|
|
|
yeah, however that ruins the nice little About Box Visual Studio is keen to provide.
|
|
|
|
|
I've tried that, but I prefer a simple MessageBox.
|
|
|
|
|
Hi,
I am currently working on printing an image from my picturebox but i am finding difficulties regarding this.
For example, I have a large image of 1024 x 768. How would i go about working out the correct size regarding the width and height
so when the image is printed, it is printed with the original width and height i.e 1024 x 768 in this example.
At the moment, i am having trouble doing this. If i do the following the image takes up all of the page(i know why) but the original
image doesnt even take up the whole page. I am using A4 piece of paper.
Here is the code:
float destHeight = bitmap.Height /bitmap.VerticalResolution * 90;
float destWidth = bitmap.Width / bitmap.HorizontalResolution * 90;
float highestHeight = destHeight / e.MarginBounds.Height;
float highestWidth = destWidth / e.MarginBounds.Width;
I would greatly appreciate if somebody could kindly assist me with this problem.
Thanks & Regards,
|
|
|
|
|
My guess: The vertical/horizontal resolution of the bitmap is not the same as the printer's resolution, so the destHeight/destWidth are getting incorrect values. You need to use the printer's resolution in your calculations.
|
|
|
|
|
Hi,
Thanks for replying. How would i go about doing this?
Would this work?
<br />
PrintDocument document = new PrintDocument();<br />
<br />
document.PrinterSettings.DefaultPageSettings.PrinterResolution.X = 300;<br />
document.PrinterSettings.DefaultPageSettings.PrinterResolution.Y = 300;<br />
<br />
Thanks,
|
|
|
|
|
The printer's resolution would probably be mentioned in the owner's manual. If not, look on the manufacturer's web site. If it's not there, send their support department an email.
|
|
|
|
|
So, I have been working on a project to allow me to query an OLAP data cube from within another program. I built a form that I use to connect to the cube, pull out the information for the user to select from, and then it creates the query.
It works great as a stand-alone application. The info is loaded using a BackgroundWorker and updates the UI as the loading completes certain levels (it can take up to a minute to load the entire cube's dimensions and lower levels.
My problem is that I built it to work in a program, that I now discover runs in a Single Threaded Apartment. Within that environment, the BackgroundWorker.DoWork event never gets called. I did a little test using the Threading.Thread model and that seems to work the way I would expect.
My question is, does anyone know why the BackgroundWorker wouldn't work within an STA and is there a way around it without rewriting my code to switch from a BackgroundWorker to the Threading.Thread model?
|
|
|
|
|
Hi William,
a lot of my programs are STA and use BGW successfully. The problem probably is with what you have inside your DoWork method; AFAIK STA will prevent multiple threads (BGW or other) to concurrently enter a COM object, so if one thread is executing code of such COM object, another thread will have to wait.
|
|
|
|
|
My problem is that the BackgroundWorker DoWork event is never even raised.
I have:
LoadCubeInBackground = New BackgroundWorker();
LoadCubeInBackground.WorkerReportsProgress = True;
LoadCubeInBackground.WorkerSupportsCancellation = True;
LoadCubeInBackground.DoWork += new DoWorkEventHandler(LoadCube);
LoadCubeInBackground.ProgressChanged += new ProgressChangedEventHandler(LoadCubeInBackground_ProgressChanged);
LoadCubeInBackground.RunWorkerAsync(_connectionString);
But, the first line of my LoadCube function never gets hit.
Right now...because converting it to the Threading.Thread model just doesn't seem like it's going to be easy, I'm looking at just starting the form as a process and having it output a string when it finishes. The whole point of the form is to end up with MDX queries, so I can just join each query into a single string, and then split it in the other program...
There are a few arguments to pass in, but they're all strings, so I can handle it with Environment.GetCommandLineArgs.
|
|
|
|
|
1. is the code shown running on the main thread? BGW does NOT behave the way one expects when created on another thread!
2. what is inside DoWork(), could you show the first few lines?
3. "the first line of my LoadCube function never gets hit." how do you observe that?
4. Environment.GetCommandLineArgs. Beware command line length limitations (could be 2K).
|
|
|
|
|
Luc Pattyn wrote: 1. is the code shown running on the main thread? BGW does NOT behave the way one expects when created on another thread!
it's run from the Form_Load event...so the main thread of the Form...though I don't know if the program that opens the form has it on its main thread or not...
Luc Pattyn wrote: 2. what is inside DoWork(), could you show the first few lines?
ADODB.Connection oCn = New ADODB.Connection();
ADOMD.Catalog oCat = New ADOMD.Catalog();
LoadCubeInBackground.ReportProgress(0, "Opening Data Cube");
ConnectionString myCStringType = e.Argument;
Luc Pattyn wrote: 3. "the first line of my LoadCube function never gets hit." how do you observe that?
I can debug with VS through the program...by that I mean, it opens the program and I can still use breakpoints and such when running my forms. This form is actually called from another form that is called from a button on the main program. So, I set a breakpoint first in the Form_Load and I set a breakpoint at the first ReportProgress in the code shown above. I can step through and see that the BackgroundWorker is created, that the event handlers are added and when I run (F5) at RunWorkerAsync...the breakpoint in the DoWork event handler never gets hit.
Luc Pattyn wrote: 4. Environment.GetCommandLineArgs. Beware command line length limitations (could be 2K).
That's a fair point...I have to pass in the sites that I'm using and there could possibly be hundreds of them...and the name's can be anywhere from 28 characters to 50+. So, I could easily reach that limit. I may just have to pass in a file name with all of the information if I can't get the better way (no command line, no starting process) to work.
I'm going to have to have an install program anyway, because it has to register the toolbar that runs all of this, so I can also install the form's exe...
I really want it to work the way I originally intended...just add the project to the original solution and add it as a new form and let everyone play well together...
|
|
|
|
|
Here is an idea: for ReportProgress to work, the main thread must be idle (the BGW invokes it, forcing it to run on the main thread). Now suppose you have some event handler that is working indefinitely, what it should not do.
Maybe the button handler itself that started it all has not finished yet. You don't have any of the following there, do you (the list is not exhaustive):
- an infinite loop
- Thread.Join
- Thread.Sleep
- network operations
- database operations
- access to some COM object that is already active on another thread while in an STA situation
Experiment: grab your title bar and move the window around. or cover part of your form with another app's window, then uncover it so it repaints immediately.
|
|
|
|
|
The form repaints fine. The whole idea was that I would load the database in the background and send the information to the UI when it was retrieved.
So, the form has a button that adds an item to a listview and then begins to load the other controls. While the controls are waiting for the info to be returned, I have a simple animated gif that displays over each until the information is returned. Right now, the form opens (which is when the bw is supposed to start). I can then click the add button...it adds an item to the listview, enables the rest of the form, and displays the animated gifs. All of it paints fine, and I can move the form around.
Here's the basic progression...
When the program loads, it checks for all registered com items.
It finds my "DataCubeUtilityToolbar" and creates it...which adds a toolbar, along with several buttons and other items.
The button that starts all of this is clicked, and it makes a call to a void within a module that creates a new "SiteSelectionWizardForm" (which is shown modally).
The user goes through the wizard to select the sites, and when finished, hit "Submit", which creates a new "ConnectionForm" (the form in question). That form is shown modally as well.
So, are you suggesting that because I showed them modally, the main program's thread isn't going to start another call until the original button call is completed? Because, I could probably show them as modeless forms...I may have to disable some stuff until the form raises an event...but if that works, I'll do it...
modified on Tuesday, April 13, 2010 6:39 PM
|
|
|
|
|
seems like you are saying somewhere is a button handler that has a form.ShowDialog() inside; this will block its thread as long as the modal dialog is open, and prevent a BGW to report progress (i.e. the progress reports will get queued, and the BGW will continue its job, but the progress reports will not dequeue until the modal form closes).
possible solutions:
- don't use modal dialogs;
- don't report progress while a modal dialog is showing;
- maybe there is some hack that makes it work, I don't know as I never got in that situation.
I suggest you perform a little experiment to confirm, e.g. temporarily replace ShowDialog() by Show().
|
|
|
|
|
I actually did try it...I made all of the forms modeless and the DoWork event still never fired. I was able to step through and see that the original program had exited the button click handler and was checking to see if items should be enabled or not, which tells me that it was allowing calls to elsewhere. The form that I wanted was still displayed, still functioning...except the backgroundworker.
I'm just going to go ahead with using Process.Start and passing in a file with the details in it...
Thanks for the help.
|
|
|
|
|
I understand.
If you ever figure it out, please let us know.
Good luck.
|
|
|
|
|
I figure it's going to have something to do with the initial program that calls it. Something in that program is screwing it up in some major ways.
I ended up trying to run it as an external process. And, it starts to work. It starts the form up, starts loading the database in the background. The events from the loading are firing correctly...and then for no apparent reason, it just stops loading the database. The UI is still functional and still works, except for the parts relying on the parts of the database that were not loaded.
I made a few changes to the code as far as what was output to the StatusLabel so that I could track the progress and it almost seems like a memory issue...as in, the program that called the process set some limits on the memory available to the program. I have 2GB of RAM and the program gets to about 34 MB and then quits the loading. Running the exact same program from a test app runs it fine. The only difference is the program that called it.
I ended up forgoing the whole thing and just loading the database and serializing the object that I created. Doing that and deserializing the object works fine. It just means that I have to implement a user option for updating the object.
The program running it just seems to screw up anything I write for it to do. It's quite frustrating. Anyway, the newest update is supposed to support multi-threading better so maybe with the newer version it will work the way that I want. Until then, a redesign of the process was the only solution.
Thanks for the help.
|
|
|
|
|
It still sounds very mysterious. 34MB isn't really that big, I would suspect something else is going wrong. Could it be you are getting a time-out, maybe on the database connection? Maybe not being the foreground process makes it get less of the CPU cycles (assuming some other process also wants them).
Anyway, thanks for the update, and good luck with it.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
