I'm currently trying to figure on HOW I can get a event/test for if an Item in a ListView is beeing displayed on the screen? The thing is I want to display the information only when it's needed (that is, when the users sees it) to optimize speed in very large ListView's.
The default implementation of the ListView class doesn't support virtual lists. Instead, you'll have to extend the ListView class with your own class and override WndProc to provide a lot of native concepts. Keep in mind that the ListView control is just a wrapper for the List View common control. There are ways you can do this, but you'll have to P/Invoke functions like SendMessage, create many differents structs, and define many enums or constants that reflect the values of all the Windows messages and notifications. See Windows Controls[^] in the MSDN Library for details. You should be familiar with Win32 APIs and programming.
You could also try searching CP or google the 'net for existing examples. It wouldn't surprise me if anyone has already done this.
Ok - I know this is a naive question, but where do I get a graphics object.
I am not in an event handler. I am in my custom control's constructor. Its not attached to anything. I just create a button and I've set the Text property, and now I want to set the Size property.
It seems that I can't create an instance of the graphics object ... and this is not a static method.
I'm not a GDI+ expert but I would guess that I can't just create a Graphics object because there is more to the drawing context that must be defined. Where am I drawing? Which window are we drawing to, etc. Maybe I can must measure the string size in the OnPaint handler (using the parameterized graphics object).
I would like to make the following custom control.
A button, that opens a drop down list. Essentially, a combo box, but I don't want the appearance of a combo box. I want a button.
My initial problem is this. The drop down list may appear outside of its parent's bounds. Imagine a thin panel on the top of a form (like a toolbar) with this control attached to it. The control may have to draw the drop down list ON TOP OF the other controls immediately beneath the toolbar.
I'm used to something like css (position: absoloute). I guess the MainMenu does this. Do I need to custom draw the drop down list control?
Why not just use a ContextMenu, which is already supported? Just start tracking the ContextMenu in the coordinate space of the container of the Button so that it aligns properly with the Button in question. See the Control.PointToClient method to convert coordinate spaces back and forth. Because the Button.Location is already in the coordinate space of the container, you could also just add the Height and Width appropriately, saving you a lot of work. The ContextMenu control will also extend past the bounds of the container.
Otherwise, you can use a simple popup Window (with the WS_POPUP style when you consider the native implementation of most controls in the .NET BCL). This is all the ContextMenu is when you get the heart of it.
Ddynamically placing the context menu might be just fine.
If I wanted more control over the look of the popup window, I may try the WS_POPUP window approach as well.
But, are you implying that I may have to use some native calls. I've written simple windows programs before - but I'm not exactly sure if thats what you mean.
Would I be on the right track to do this natively by - creating a WS_POPUP window and writing a wndproc to catch mouseover, mouse out and click events? I've seen several posts that link to native DLLs and use SendMessage, etc, so I think I could work this out.
But, I just want to be sure that I'm not missing something ... like, creating a panel in C# and somehow makeing it visible and invisible lower than the button I am using to trigger it. I've tried this - and at first attempt, the panel always shows up UNDERNEATH the controls lower in the client area.
I'm betting I can get that final idea could work if I could somehow make change the panel's z order to higher than the controls lower in the client area. The hypothetical problem I can think of is that the controls lower in the client area don't attach to the same parent, and so, maybe this is recursive so I need to trace back until the parents attach to the same form or root panel, and makes sure the popup menu parent is at a higher z index ...
If you have more time, your suggestions are greatly appreciated. For now, I'm off.
A Panel won't work because it's a child window and nothing more. You have to use a popup window because it must be able to extend beyond its container's bounds. You could use a Form, but there's just too much overhead, IMO.
Yes, what I was talking about was good ol' Win32 programming. Fortunately, .NET can help even there. Remember that all the controls in System.Windows.Forms are just wrappers of Common Controls. There's even classes like NativeWindow that can give you a wrapper to a native window. It wouldn't be too difficult to do. I'm sure there's examples out there, too, although good, specific keywords might be hard to determine.
The Microsoft Jet provider is used to access .mdb files, which are commonly equated with Microsoft Access, though MS Access is not needed to create and use these .mdb files (it's just really handy, and I believe required for forms and reports manipulation).
So what's the question? The Microsoft Jet provider for .mdb files doesn't support retrieving parameters from stored procedures, which really are only module functions.
If you need a real RDBMS, look into the Microsoft Data Engine (MSDE) at http://www.microsoft.com/sql/msde/default.asp[^]. This is Microsoft SQL Server with a few limitations, like the number of concurrent connections supported (10). Other than that, it supports true stored procedures, triggers, tables and views (of course), functions, and everything else that SQL Server supports. It is also freely redistributable so long as you have a valid license for a product that includes the MSDE, like Visual Studio .NET, Microsoft Access (I think), an MSDN Subscription, and several others things. It's also a free download.
You can install up to 16 instances of the MSDE and SQL Server (think of them as the same thing). Microsoft Access even supports direct access and designing with the MSDE if you still want to design your databases using MS Access.
Basically, though, you get a real RDBMS that is much faster and supports everything any other RDBMS like Oracle and DB2 does. It also supports output parameters in stored procedures and has better support in .NET using the System.Data.SqlClient namespace, which is written specifically for SQL Server and you don't have to guess at what is supported. System.Data.OleDb is based on OLE DB and uses abstract OLE DB providers that must provide some basic functionality, but don't have to provide any of the optional stuff.
For instance, in an article I wrote I use the Microsoft Indexing Service OLE DB provider. It only supports basic SELECT statements and views using an OleDbCommand. Period. No updates, no insertions, no transactions, no stored procedures. You're left to the will of the OLE DB provider.