|
Buggary
I saw that section and speed read it, assuming it was some inconsequential bug
|
|
|
|
|
Sooooo
Does anybody have any experience of using Transparent BLT in C#?
|
|
|
|
|
Just expose the item you want from the dialog by using a property. As long as your dialog object is still in scope, you can grab properties from it even though the window no longer dislplays. For instnace:
MyDialog dlg = new MyDlg();
string info;
if( dlg.ShowDialog(this) == DialogResult.OK )
{
info = dlg.Info
}
-------------------------
public string Info
{
get { return _info; }
}
Hope that helps.
-Matt
------------------------------------------
The 3 great virtues of a programmer:
Laziness, Impatience, and Hubris.
--Larry Wall
|
|
|
|
|
I am currently planning a football stats project for the local football teams (in C# of course  ). It's going to be a Windows Forms app. So should I use XML or a database?
There won't be more than one user on the data store at any one time, so it's just a matter of what one is easier to adjust dynamically.
Any Pros & Cons to using an Access DB over XML or vice versa?
--Thanks for any advice.
********************
* SteveMcLenithan
* steve@steve-mac.com
* http://steve-mac.com
********************
|
|
|
|
|
Using Access at all can be a con in itself. That being said, you can't beat it for portability and cost effectiveness. The only thing I would keep in mind there is that there is, to my knowledge, no easy way to create Access databases on the fly in C# shy of using ADOX and COM+. If you don't need to creat the database programmatically, though, it's a moot point.
As far as XML goes, you should really just ask yourself why you would use it. XML, while a great and useful technology, isn't the right choice for every application. It sounds to me like you are just wanting to store some simple data that you will manipulate. I would personally go for the database just because it is fairly easy to use and the development time would be pretty quick. Adding XML, on the other hand, could produce unnecessary overhead and time consumption.
If it's your goal to learn more about XML, then it may be worth it to try it that way, but if you're under a time crunch, I would personally go for the straight SQL with a database--primarily because that is what I'm most familiar with, but also because using XML doesn't really give you an added benefit. IMHO
-Matt
------------------------------------------
The 3 great virtues of a programmer:
Laziness, Impatience, and Hubris.
--Larry Wall
|
|
|
|
|
perlmunger wrote:
but also because using XML doesn't really give you an added benefit. IMHO
And when the app invariably needs to scale to more than one concurrent user you run into fun problems  *says Paul from stupid experience*
Paul Watson
Bluegrass
Cape Town, South Africa
Ray Cassick wrote:
Well I am not female, not gay and I am not Paul Watson
|
|
|
|
|
Thanks for the input. I think I'll stick with the Access DB. At most there will be two different people editing at the same time but always with different tables.
Thanks
********************
* SteveMcLenithan
* steve@steve-mac.com
* http://steve-mac.com
********************
|
|
|
|
|
I have sucessfully wrapped existing C++ code that controls dialogic telephony hardware into one nice managed dll file.
Here is an interface from the origional Managed C++ DLL
---------------------------------------------------------
#pragma once
#using <mscorlib.dll>
using namespace System;
namespace Telephony
{
public __gc __interface ITelephony
{
public:
// METHODS
void ClearDigitsBuffer();
void Dial( String __gc* phoneNumber);
String __gc* GetDigits(int maxDigits, float timeOutSec, String __gc* termDigits, float digitTimeOutSec, float silenceTimeOutSec,String __gc* &termDigit);
String __gc* GetDigits(int maxDigits, float timeOutSec, String __gc* termDigits, float digitTimeOutSec);
void GiveDialTone();
void OffHook();
void OnHook();
void PlayFile(String __gc* fileName, String __gc* termDigits, bool terminate);
void PlayFile(String __gc* fileName);
// PROPERTIES
__property String __gc* get_CallerId();
};
}
---------------------------------------------------------
The above worked perfectly...
I have since decided that it would be beter if I had taken the ITelephony interface out of the dialogic dll and placed it in a more generic dll file that can used to implement future wrappers for other Telephony hardware.
For this task I decided to use C# and the following is the result...
---------------------------------------------------------
using System;
namespace Telephony
{
public interface ITelephony
{
// METHODS
void ClearDigitsBuffer();
void Dial(string phoneNumber);
string GetDigits(int maxDigits, float timeOutSec, string termDigits, float digitTimeOutSec, float silenceTimeOutSec, ref string termDigit);
string GetDigits(int maxDigits, float timeOutSec, string termDigits, float digitTimeOutSec);
void GiveDialTone();
void OffHook();
void OnHook();
void PlayFile(string fileName, string termDigits, bool terminate);
void PlayFile(string fileName);
// PROPERTIES
string CallerId
{
get;
}
}
}
---------------------------------------------------------
When I recompiled the solution I noticed that any C++ class that inherited from the C# interface was now considered abstract. To confirm this I used ILDASM
---------------------------------------------------------
.class public abstract auto ansi Line
extends [mscorlib]System.Object
implements [Telephony]Telephony.ITelephony
---------------------------------------------------------
I have since found a work around for this problem by instead creating the generic dll in managed C++ using the origional C++ interface from above. Now when I use ILDASM I see this...
---------------------------------------------------------
.class public auto ansi Line
extends [mscorlib]System.Object
implements [TelTest]Telephony.ITelephony
---------------------------------------------------------
Have I made a mistake in converting my C++ interface into C# or is there a noted problem when creating C++ classes which inherite from C# interfaces?
Thanks,
Any help would be appreciated
|
|
|
|
|
Or how to return parametr to main wnd, when my modal dialog is closing?
|
|
|
|
|
Set the OK button's DialogResult property to OK. Then use this code in the main/calling form.
frmInput dlg = new frmInput();
if(dlg.ShowDialog(this) == DialogResult.OK)
{
// Code to run on OK
}
|
|
|
|
|
OK, it works, thanks.
But it I need to get some data from my modal dialog?
If I'm typing some string and after closing dialog i need to add this string into my listbox on main window?
=====================
http://wasp.elcat.kg
|
|
|
|
|
Hi guys,
I'm writing some controls to build skin application,and I would like to apply skin to the scroll bar. Because I can not change system scroll bars I think to hide the listbox scroll bar with this code:
int sb=Convert.ToInt32(ScrollBarTypes.SB_VERT);
WindowsAPI.ShowScrollBar(_toScroll.Handle,sb,0);
In my skin scroll bar code when I want to scroll I use this code:
int scroll=Convert.ToInt32(Msg.WM_VSCROLL);
IntPtr hwnd=_toScroll.Handle;
int hiword=Convert.ToInt32(ScrollBarRequests.SB_THUMBPOSITION);
int par=Convert.ToInt32(0x10000);
int par2=65535;
Debug.WriteLine(Value);
IntPtr index=new IntPtr(((Value-1) * par) | (hiword & par2));
WindowsAPI.SendMessage(hwnd,scroll,index,new IntPtr(0));
It runs correctly but each time the listbox scrolls, the system scrollbar remains visibile
Are there other methods to scroll the listbox?
|
|
|
|
|
I work on a company that makes heavy use of the COM\ATL framework for C++ component based programming. We would like to move to .Net\C#, but haven't quite resolved how to achieve all of our criteria. Outstanding issues are:
1. Type libraries
I don't yet see a concept of a binary type definition file in C#. Every C# example I've seen that defines an interface does so in a .cs file.
public interface ISayHello
{
// define properties and methods
}
This has two problems: you cannot register your interface (tlb's can be registered) and it is editable(I like giving out tlb's, knowing that the interface won't be tampered with). Can you still use idl in C#? Can you import tlb's?
2. Registry Groups
We register our COM components using a registry groups. This allows us to programmatically query the registry for a list of our company's servers. It is very important for us to be able to filter the registry contents in this way. I think I understand that the global assembly cache now replaces the registry, but I don't see a way to programattically search it, much less search it with a group filter.
3. MTA\STA
We currently create our servers in the MTA for performance reasons, and because it's more deterministic. Is there a MTA\STA concept in .Net? Is there still a message pump?
Sorry for the long post. I'd appreciate whatever advise, links or book titles that come to mind.
Aaron
|
|
|
|
|
AaronStibich wrote:
This has two problems: you cannot register your interface (tlb's can be registered) and it is editable(I like giving out tlb's, knowing that the interface won't be tampered with). Can you still use idl in C#? Can you import tlb's?
The .cs file is just the source like a .cpp file with VC++. You will compile your code into an assembly .dll. Under the .NET Framework there are no IDL files.
AaronStibich wrote:
We register our COM components using a registry groups. This allows us to programmatically query the registry for a list of our company's servers. It is very important for us to be able to filter the registry contents in this way. I think I understand that the global assembly cache now replaces the registry, but I don't see a way to programattically search it, much less search it with a group filter.
All strongly named assemblies can be installed within the GAC (Global Assembly Cache). This would allow you to install (for example) 4 different versions of myCode.dll and they are all still accessable. I will have an article coming up soon explain more on this. You may be able to expose the meta data somehow, not sure right now.
AaronStibich wrote:
We currently create our servers in the MTA for performance reasons, and because it's more deterministic. Is there a MTA\STA concept in .Net? Is there still a message pump?
There has been a lot of fuss of deterministic finalization, most people say that it no longer exists. The .NET Framework implements garbage collection so this is kind of a touchy subject. You can override the WndProc like this:
protected override void WndProc(ref System.Windows.Forms.Message m)
{
<font color="green">
base.WndProc(ref m);
}
Hope this helps some. 
Nick Parker
May your glass be ever full.
May the roof over your head be always strong.
And may you be in heaven half an hour before the devil knows you’re dead. - Irish Blessing
|
|
|
|
|
Nick Parker wrote:
Under the .NET Framework there are no IDL files
With .NET, everything is an IDL file. Remember that IDL files where used to allow marshalling accross process boundaries, now with the .NET virtual machine marshalling is everywhere to convert types according to the needs.
AaronStibich wrote:
Is there a MTA\STA concept in .Net?
You can attach the [STAThread] or [MTAThread] attribute with the entry-point of your application, but it only has an effect when this application uses COM interop.
AaronStibich wrote:
Is there still a message pump?
The current .NET CLR is a mixture of the old windows message world and the event model world (introduced by java as far as I know). So yes, you can still do so but when you are using explicit SendMessage calls or other stuff, you are in fact faking .NET.
COM components belong to the C++ world. They are not needed anymore in a .NET environment, except for legacy reasons (tons of COM/ActiveX components used in the real world).
Back to real work : D-23.
|
|
|
|
|
.S.Rod. wrote:
With .NET, everything is an IDL file.
The reason I said there were no IDL files is because just the other night Terry Leeper from MSFT gave a speech that I listened to and he said in his presentation that IDL files are no longer. 
Nick Parker
May your glass be ever full.
May the roof over your head be always strong.
And may you be in heaven half an hour before the devil knows you’re dead. - Irish Blessing
|
|
|
|
|
That's correct. The release of the CLR marks the death of COM.
Back to real work : D-22.
|
|
|
|
|
.S.Rod. wrote:
That's correct. The release of the CLR marks the death of COM.
 Ok, are you contradicting yourself or agreeing with me?
Nick Parker
May your glass be ever full.
May the roof over your head be always strong.
And may you be in heaven half an hour before the devil knows you’re dead. - Irish Blessing
|
|
|
|
|
I agree with you.
Back to real work : D-22.
|
|
|
|
|
.S.Rod. wrote:
Back to real work : D-22.
Could you explain this, I think I have read it in your posts since it said D-28. What does it mean, are you counting down days or something?
Nick Parker
May your glass be ever full.
May the roof over your head be always strong.
And may you be in heaven half an hour before the devil knows you’re dead. - Irish Blessing
|
|
|
|
|
In 21 days, I am employed again.
Back to real work : D-21.
|
|
|
|
|
.S.Rod. wrote:
In 21 days, I am employed again.
Hey, congratulations and good luck. 
Nick Parker
May your glass be ever full.
May the roof over your head be always strong.
And may you be in heaven half an hour before the devil knows you’re dead. - Irish Blessing
|
|
|
|
|
Is there support for using .ini files in C#? I can't seem to find it anywhere. Is there a substitute for this (I don't want to use the registry)?
Thanks for your help!
dpb
Darryl Borden
Principal IT Analyst
darryl.borden@elpaso.com
|
|
|
|
|
Darryl Borden wrote:
Is there a substitute for this (I don't want to use the registry)?
How about just using an XML file, I believe this is the "way" some apps are going now because it is so easy to work with them inside the Framework.
Nick Parker
May your glass be ever full.
May the roof over your head be always strong.
And may you be in heaven half an hour before the devil knows you’re dead. - Irish Blessing
|
|
|
|
|
Can you show me an example how to read\write data to a xml file?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
