That was what I originally did, but I keep getting invalid identifier errors with SQL Server 2K. I was hoping this was just something specific to T-SQL, as opposed to the syntaxes I am more familiar with. There must be a switch I'm incorrectly setting somewhere, since your script files parse correctly. Thanks for confirming my original approach is not what I need to change. Cheers

I am creating tables dynamically using stored procedures, and would like to use a parameter variable as the table_name identifier. The SPs are implemented in T-SQL scripts. I am currently using literal identifiers as usual, then renaming the tables via sp_rename. For example (with SET QUOTED_IDENTIFIER ON):

CREATE PROC spCreateTable (@TableName sysname)
AS
BEGIN
CREATE TABLE "_TempTableName_" (
/* ... */
)

EXEC sp_rename '_TempTableName_', @TableName --rename to desired name
END
GO

Does anyone know how I could use @TableName directly or indirectly in the CREATE TABLE statement?

.S.Rod. wrote: ...(at least something that stands for itself in this .NET run-time). Why Stephane, I haven't noticed your using that "smiley" before. ;) If I didn't know better, I'd say you are among those of us who have been wrestling with the insanity of the software industry for so long... "Few are those who see with their own eyes and feel with their own hearts." - A. Einstein

Usually it's untyped datasets that are considered more limited than typed ones, unless you are accessing data you know little about. However, it really depends on what you want to do. Typed datasets essentially just means the types are known and understood, whereas untyped ones are generic, and hence less is known (and needs to be known). Typed sets are much more efficient, since more work is done at compile time than at runtime. Also, typed sets can do more error checking to avoid mistakes. Commonly, the goal is to use typed sets whenever possible. Untyped sets can be a little simpler at first, since less needs to be specified, column names do not need to be known, etc. If you do need to work with untyped sets at some point, it's useful if you can have a schema automatically generated, so you can move to typed sets. That will depend on the situation, though. If you do not consider needing to know what types to deal with to be a problem, then I cannot think of any serious limitations with typed datasets. Cheers

hkulten wrote: Eclipse 2.0 is a good one ! I completely agree. Although Eclipse is written in Java, it uses SWT GUI components, which are much faster than Swing. Sun's IDE is slow and error-prone. Cheers

Thanks for your support too, James. Cheers

Thank you Chris, that's exactly what the doctor ordered :) It's a pleasure to have contributors such as yourself on CP. Incredible that I overlooked that in the docs; probably scanned the protected methods too quickly, and got lost in keyword searches! Cheers

Robert Hinrichs wrote: BTW the politically correct name for a global variable is "Well Known Object" Well said. And there are no global functions either, only statics, which preserve the purity of the OO paradigm. ;) Cheers

Has anyone succeeded in spawning a modeless dialog that stays on top of the main form, but that does not just stay on top of every window in the shell? That is, behaviour identical to Find/Replace dialogs in VS and Office. In C++ this is routine, but in .Net I have failed when: 1) Setting dialog's TopLevel to false, and making dialog a child of main form. This only allows rendering the dialog within the client area of the main form, of course, since it is treated as a non-form child control. 2) Using Win32 API SetParent() and SetWindowPos() directly. The dialog freezes and paints garbage. CLR does not recognise Windows' way of setting parent-child relationships, I suspect, and proper message handling requires the dialog to be in the parent's collection. I am investigating some wild hacks, but would appreciate it if anyone has insights on this. TIA

Jonathan de Halleux wrote: how do I match # ? Same as any other non-reserved character, such as letters of the alphabet. The only time it needs to be escaped ("\#") is if you use the RegexOptions.IgnorePatternWhitespace flag. Cheers

Adequate efficiency is not usually something that can be predicted, so you might just have to test things. However, even if you were not making cross-thread calls, thousands of calls in a short period of time (say milliseconds) is not as efficient as batching some data together. This would be especially true if each call only passes a small amount of data. Cross-thread calls will add to execution time, but may or may not be the crucial factor. If things aren't happening as fast as you'd like, it can't hurt to try batching some data together. Also, keep in mind that Invoke() is synchronous, so each call will wait for completion. BeginInvoke() might be worth looking at, since it is asynchrous, and will return immediately. However, it might be less attractive if the data needs to be synchronised. Which one to use really depends on the particular situation. Cheers

As leppie posted, there are many useful functions in the Marshal class, which is good to become familiar with if you are interfacing with external C or C++ functions. IntPtr itself also has useful methods, such as ToPointer() and ToInt32(), along with the statics Zero and operator overloads that can convert between void pointers and IntPtr types. Which ones to use depends on how you plan on calling the extern functions. It is hard to explain the usage details without seeing a code example. If you could post one with how the calls are intended to be made, and how the parameters are to be passed, I'm sure I could explain a solution. Regarding using the extern funcs you currently have, if the calling C# func is declared unsafe, then you can just cast your "ints" as in regular C code (including pointers and taking addresses). Or you can prototype the externs as unsafe from the start like: DLLImport("rv.dll", CharSet=CharSet.Ansi, CallingConvention=CallingConvention.Cdecl)) public static extern unsafe int f(void *pVoid); DLLImport("rv.dll", CharSet=CharSet.Ansi, CallingConvention=CallingConvention.Cdecl)) public static extern unsafe int f2(void **ppVoid); If you are looking to do this using the non-unsafe runtime interop features, you could do: DLLImport("rv.dll", CharSet=CharSet.Ansi, CallingConvention=CallingConvention.Cdecl)) public static extern int f(IntPtr pVoid); DLLImport("rv.dll", CharSet=CharSet.Ansi, CallingConvention=CallingConvention.Cdecl)) public static extern int f2(IntPtr ppVoid);

Hello Paul, Paul Selormey wrote: MC++ is here to stay!!! Yes it is! In fact, I'm counting on VS.Net 2003 making it a lot more popular. Looks like we'll be some of the few ahead of the game. Cheers, Jeff

Hello Andre (and Paul), I played with the code you posted and some other stuff, but could not find a way to optimise the MC++ MSIL any further, but that may not be as much of a problem as we first thought. BTW, I can now see your MSIL was taken from optimised compiles. Regarding your earlier question of whether the C# struct was being allocated on the stack or on the heap, I think I judged too quickly based on the MSIL. CIL documentation does not say much about newobj being applied to value types, however it "can" be used to allocate on the stack. It also says that it is rarely done this way. The blanks leave questions, but my guess is that newobj is itself optimised to return value types/structs as efficiently as possible, and in this unusual case, not on the heap. CLI instructions are not like low-level assembler op-codes, but more like convenient groups of instructions (actually, so are some op-codes). Frustrated with MSIL, I moved to assembler, and found the following:

static MCppStruct GetStack() | public static CshStruct GetNew()
{ return MCppStruct(1,2,3); } | { return new CshStruct(1, 2, 3); }

00 push ebp | 00 push ebp
01 mov ebp,esp | 01 mov ebp,esp
03 sub esp,10h | 03 sub esp,10h
06 push edi | 06 push edi
07 push esi | 07 push esi
08 push ebx | 08 push ebx
09 mov ebx,ecx |
0b lea edi,[ebp-10h] |
0e xor eax,eax | 09 xor eax,eax
10 stos dword ptr [edi] | 0b mov dword ptr [ebp-10h],eax
11 stos dword ptr [edi] | 0e mov dword ptr [ebp-0Ch],eax
12 stos dword ptr [edi] | 11 mov dword ptr [ebp-8],eax
| 14 mov ebx,ecx
13 push 2 | 16 push 2
15 push 3 | 18 push 3
17 lea ecx,[ebp-10h] | 1a lea ecx,[ebp-10h]
1a mov edx,1 | 1d mov edx,1
1f call dword ptr ds:

Smitha Vijayan wrote: What is the quickest way to convert an image to a byte array? I am not sure if you mean performance or easiest to code, but you can just use the Image's Save method, and pass a MemoryStream instead of some sort of file stream. A MemoryStream can write to an array of bytes. Saving to a file would be very slow in performance, and not necessary in this case. Cheers

The IntPtr type can handle void pointers. In fact, it has static methods specifically for dealing with them. Incidentally, "unsafe" doesn't mean "not safe to do", as the name implies. It just means the runtime cannot verify the types and such for us. I read somewhere that the name was chosen to scare unseasoned programmers away from using it. Internally, the CLR uses unsafe all the time. Cheers

Hello Andre, VizOne wrote: ...is the C# version creating the object on the heap or the stack? As you suspected, the C# version is allocating on the heap, which is what the 'newobj' IL instruction normally does. So, the two pieces of code are not equivalent, and is partly why the instructions differ so. The MC++ bit is dealing with a stack object, and even more importantly, is returning a copy of the object, not just a pointer (object reference in .Net lingo) to it. The 'ldobj' instruction verifies this, and I think a large part of the performance difference. Not only is the __value object initialised (initobj Cpp.MyStruct), but it's address is repeatedly pushed onto the stack (ldloca.s V_0) for various ops. So the address of the static struct is loaded, it's initialised, the address is again loaded, constant params loaded, the ctor called, the object's address loaded yet again, then an entire copy made before returning. I can see why performance was bad. However, I'm thinking the number of ops is not the most reliable way to gauge performance here. In particular, newobj does a lot for a single instruction, including runtime allocation on the GC heap, initialising, and then calling the ctor. Admittedly GC heap allocation is designed to be very fast, and nearly as fast as stack allocation, but the C# code does not make a copy. I suspect that's the biggest factor. I'm curious if the code was optimised during compile, as that might make a significant difference. You have me digging deeper into this one, so I'll post back if I come up with anything more. I'll try making the MC++ and C# functions both return copies and pointers. Shame on you for stimulating my attrophied neurons! ;) Interesting stuff. Cheers

I'll have to remember that, thanks for the heads-up. I suppose I should be glad I wrote a binary editor derived straight from Control, as I can see I would have had the problems you're having. Of course, much of TextBox's functionality didn't apply for me. Still a pain in the "details", so I see why you're trying to avoid it. Still, I'm curious as to why the problems. I'll post back if I find anything.

Hi VizOne, Sorry for the late reply. VizOne wrote: But what about __value object? They are stored on stack, aren't they? Will stack object be move during collection, too? Although __value objects are typically stored on the stack, they can also be put on the heap. Stack objects are the same in .Net as they are in regular C/C++, so they won't move. How heavy would you say is pinning a pointer? Is it a real performance issue if I keep the pointer pinned only for some native calculations that won't last more then a view microseconds? I did some preliminary tests too, and I could barely measure any performance differences. I forced GC collections during them. The GC does not collect very often under normal circumstances, so I don't see pinning as costly either. Your tests jibe with mine. Of course reinterpret_cast is an evil monster, but I have to use it here, haven't I? I always do, and MC++ code that ships with .Net uses it too. I really think MS is just playing it "safe". As I recall, reinterpret_cast was just discouraged. The software world would grind to a halt if such casts were never used ;) The reinterpret_cast is safe and ok, or not? I usually call native functions from MC++ much like you do. As long as managed objects are pinned and the cast is appropriate, safety should not be of concern. Cheers

You didn't say, so just to confirm: are you are inheriting from TextBox or TextBoxBase, and explicitly overriding OnPaint and OnPaintBackground, and are calling SetStyle with the ControlStyles.UserPaint (and optionally AllPaintingInWmPaint and DoubleBuffer)? If you comment-out the normally-required base.OnPaint call, the text is still rendered by the CLR stuff?