|
Hi,
I am trying to make a kind of desktop widgets using C#. So far, I've managed to create a window that gets added to the WorkerW window containing SHELLDLL_DefView. This way, my main form is inserted inside the desktop window over the wallpaper. This is exactly what I want except that I have a little problem. It seems like there is an opacity of 50% and a black is rendered as transparent. I don't know where this comes from and I don't know if I can change it. Does anybody knows what might be causing this and how can I fix it?
The code I used to do this is pretty simple. I find the handle to the WorkerW window that contains the SHELLDLL_DefView window as a child and then I call those functions to insert my own form inside as a child :
SetParent(this.Handle, hWndParent);
SetWindowLong(this.Handle, -16, new IntPtr(GetWindowLong(this.Handle, -16) | 0x40000000));
Here's how it looks when the form is in the desktop
Thank you
|
|
|
|
|
If you are trying to create a desktop widget then do some research with the Sidebar Gadget projects. The way you are doing it could be problematic.
Regards,
Thomas Stockwell
Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.
Visit my Blog
|
|
|
|
|
After creating a VB.NET app in .NET Framework 4 I noticed that when I try using the application on several levels of windows whether it be XP/Vista or 7 it keeps throwing an error bout installing the suggested framework on the computer. How do I compile it so it is compatible with several OS's without the user having to install the .NET Framework in order for it to run?
|
|
|
|
|
Sorry to tell you, but if you build an application in dotNET 4.0, any computer that will attempt to execute the application will be required to have dotNET 4.0 installed, there is no way around that as the dotNET 4.0 assemblies provide the "under the hood" functionality that your application utilizes. About the only way to be a little more backwards compatible would be to target your project(s) to dotNET 2.0 and refactor any code that requires it to run in that mode.
|
|
|
|
|
.Net 4 apps require .Net 4
However you could add the .Net 4 prerequisite to you installer package to ensure it gets installed before your app runs.
|
|
|
|
|
If you don't need the latest features, you could target say 2.0 AND somehow tell your code will also run happily on higher .NET versions (for the rare situation a system has say 4.0 and no 2.0). I don't know the details, uncle Google knows for sure.
ADDED
Whatever targets 2.0 also runs fine on 3.0 and 3.5, as these are functional and technical supersets of 2.0
4.0 is a completely different thing; it is a functional superset too, but consists of all new files
1.0 and 1.1 should be considered obselete IMO.
/ADDED
|
|
|
|
|
Herboren wrote: with several OS's without the user having to install the .NET Framework in order for it to run
You need the right framework installed.
Or you could use multitargeting to compile your program in another version of .Net (provided you are not using features specific to .Net 4). But then you would still need that framework installed.
The funniest thing about this particular signature is that by the time you realise it doesn't say anything it's too late to stop reading it.
My latest tip/trick
Visit the Hindi forum here.
|
|
|
|
|
Target the runtime version which you think would be installed on all your target client OS.
|
|
|
|
|
Hi,
I have read many times that ADO.NET is disconnected architecture.
But the datareader object requires open connection while fetching that data.
Please share your views on this.
Regards,
Amol
|
|
|
|
|
Amolravatale wrote: Please share your views on this.
Methinks it requires an open connection while fetching, and that it's closed when it doesn't. So, by default the connection is closed, and only opened when required.
I are Troll 
|
|
|
|
|
Eddy Vluggen wrote: Methinks it requires an open connection while fetching, and that it's closed when it doesn't. So, by default the connection is closed, and only opened when required.
That really depends on how you set up the reader. Closing the connection isn't obligatory - good practice, but not mandatory.
|
|
|
|
|
Pete O'Hanlon wrote: That really depends on how you set up the reader.
True, but the question was about the disconnected architecture. Whether one closes the connection (and the reader) doesn't change the principles.
Yes, it depends a bit on the reader, it might have been initialized with the argument to close the connection once the reading is done. You might also want to keep an open connection for a second command that gets executed, but the idea behind the disconnected architecture is to close the connection when you're done.
That depends on the programmer, and is a best practice again. It's not mandatory, you can open a single connection for your app and keep it open for the lifetime of the application. I'd rather see it closed, or better yet, encapsulated with a USING statement.
I are Troll
|
|
|
|
|
In that one case, no, it's not disconnected. In other cases, where a dataset is returned or some other operation, yes, it is.
|
|
|
|
|
Dave Kreskowiak wrote: where a dataset is returned
DataAdapters use DataReaders -- but they're smart enough to open and close the connection as necessary.
|
|
|
|
|
Dear All,
Thanks for this discussion.
Regards,
Amol
|
|
|
|
|
PIEBALDconsult wrote: DataAdapters
Which work with DataSet/DataTables... 
|
|
|
|
|
Do you know of another means of retrieving data that does not involve a connection to the database at some point?
I know the language. I've read a book. - _Madmatt
|
|
|
|
|
Sounds like a data input requirement I had a while back.
"The data must be entered into the database without using an import process, nor any keyboard interaction"
I was thinking, voice recognition, or maybe psychic powers.
|
|
|
|
|
Amolravatale wrote: ADO.NET is disconnected architecture
IMO, depends on how ADO.Net is implemented really.
The funniest thing about this particular signature is that by the time you realise it doesn't say anything it's too late to stop reading it.
My latest tip/trick
Visit the Hindi forum here.
|
|
|
|
|
Having a disconnected architecture does not have anything to do with which objects require shorter or longer connection time. You need to first understand the basic principle and definition od a disconnected architecture.
In traditional data access components, you make a connection to the database system and then interact with it through SQL queries using the connection. The application stays connected to the DB system even when it is not using DB services. This commonly wastes the valuable and expensive database resource as most of the time applications only query and view the persistent data. ADO.Net solves this problem by managing a local buffer of persistent data (data set). Your application automatically connects to the database server when it needs to pass some query and then disconnects immediately after getting the result back and storing it in dataset. This design is very much similar to the connection less services of http over the internet. It should be noted that ADO.Net also provides the connection oriented traditional data access services.
Another important aspect of the disconnected architecture is that it maintains the local repository of data in the dataset object. The dataset object stores the tables, their relationship and different constraints. The user performs operations like update, insert, delete to this dataset locally and finally the changed dataset is stored in actual database as a batch when needed. This greatly reduces the network traffic and results in the better performance.
|
|
|
|
|
Arjun Bahree (TechnoMatrix) wrote: The user performs operations like update, insert, delete to this dataset locally and finally
... the application crashes and all the changes are lost. 
|
|
|
|
|
Connect when you need access. Disconnect when you don't.
When using a DataReader or performing a sequence of operations within a transaction, you need access.
|
|
|
|
|
I created org chart using trial version in C#.net dynamically using mysql database, it is running only in localhost. If i want to run IIS it is giving message like u have to purchase and i am not able to view that chart. Is there any alternation solution to view that chart and it can run in IIS server. If anybody knows please reply me. Thanks in advance.
modified on Friday, September 10, 2010 12:57 AM
|
|
|
|
|
You could consider supporting the devs who wrote the tool and buy the damn thing.
|
|
|
|
|
I appreciate that we have some clever people here in the forums, but even they need some help now and again. How about clarifying some points, such as what the software is that you are trialling? It could be that there's a restriction in there that prevents things from being viewed from anything other than localhost.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
