Re: MR. Heath Stewart come in please - C# Discussion Boards

22-Nov-03 2:21

I found www.thecodeproject.com just before a week.Next week i asked a question "how to control web components in winform by embeding a browser(ie)" and i didn't thought so many people have took focus on it.So i am appriciated your help.But i am a beginner of programmer,so can you offer me a specific application example that is windows applicatin embeded a browser and we can draw Web componet such as TextBox on the browser interface?thank you for your help very much. myEmail:kiss1979@sohu.com

ok

Heath Stewart22-Nov-03 4:15

22-Nov-03 4:15

I have an older example on a different site that I'm currently porting to CodeProject. Source is available from that site as well. The site itself bites.

-----BEGIN GEEK CODE BLOCK-----
Version: 3.21
GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++
-----END GEEK CODE BLOCK-----

nakey_yang22-Nov-03 15:26

22-Nov-03 15:26

if i put a div element on the face of browser and set webconpontnet on the div, through this method can get the same result?

ok

Heath Stewart24-Nov-03 4:15

24-Nov-03 4:15

No, you have to use the <object> tag. Please read my article and for more details, see Deploying a Runtime Application in Internet Explorer[^] in MSDN. If you give the control and ID and you create a class interface for the control that uses [InterfaceType(ComInterfaceType.InterfaceIsIDispatch)] attribute (on ther interface), with [ClassInterface(InterfaceType.None)] on the control (which implements the class interface as the first interface), you can access properties and call methods on the control like any other ActiveX controls. You should not use InterfaceType.AutoDual or InterfaceType.AutoDispatch for the class interface. See Nick Parker's Creating a CCW for COM-enabled non-.NET Applications[^] for more details.

nakey_yang24-Nov-03 20:02

24-Nov-03 20:02

I know you mean,that is use winform control in web application.The method just as using ActiveX in web. But the .net framework is required in client.
Did you mean we can move the control in web using the method you tell about a week ago?

thank you!

Heath Stewart25-Nov-03 2:57

25-Nov-03 2:57

Of course an embedded Windows Forms control requires the .NET Framework to be installed on the client, just like Java applets require a JRE and ActiveX requires IE. If you read my article, you'd see that this is treating a Windows Forms control in a similar fashion to an ActiveX control (it uses the <object> tag with a different classid value), and it can be scripted so long as the control uses dispatch interfaces (automation) that are exposed to the scripting host. It's all in my article.

Note, though, that this has nothing to do with ASP.NET. It can be embedded into plain HTML documents, ASP, PHP, or anything, since it is completely client-side.

nakey_yang26-Nov-03 22:03

26-Nov-03 22:03

i see.
Now i am designing a application that enable users as server side can configurate some componets on the platform (just a winapplication embedded browser i said first time) the users as client side can watch the results.As you know the client side should comunication with server realtime to get data.
Cmmonly we can refresh the browser to link to the server to get data,but when application need do this per 2 second this method cann't been used.Now i am confused about whether to design web components(how keep communicaion between server and client in background process) or winform component (use DCOM to keep their communicaion?anyother method?) .So, please give me some advice. thank you.

非常感谢您的帮助

Heath Stewart28-Nov-03 3:30

28-Nov-03 3:30

Web Controls are merely server-side controls that are rendered as HTML. This would still require that the client refreshes the browser, or that you initialize a timer with a 2-second delay, or that you use the HTTP header "refresh" (or a META tag using http-equiv="refresh") with the value "timeout;url", where timeout is set to 2 and the url is the same page.

If you use a Windows Forms control, you could use XML Web Service, Remoting, or Enterprise Services (DCOM) to communicate in real-time with the backend with the user needing to do anything, but the client should still poll for data (if using remoting hosted by IIS) because any remoting object hosted by IIS is configured as a Web Service and - because of the HTTP protocol - can only communicate one way (from client to server).

nakey_yang1-Dec-03 14:57

1-Dec-03 14:57

Now,i am decided to design Web component.Just as you say above if we design winfrom component we can use web servers,DCOM and so on,but when i do web component,how can i keep communication between client and server don't use to refresh.For example when i use DataGrid web component ,how can i update its data in client side without using refresh to connect to server side.

感谢你的帮助！！！

Heath Stewart1-Dec-03 18:27

1-Dec-03 18:27

The important thing to remember is that the web browser is not communicating the with server. The server nearly sent the browser a page that contains an embedded object. That object communicates directly with the server as any other application - either embedded or standalone - would, using remoting, DCOM, or whatever. This is up to the implementation.

nakey_yang3-Dec-03 15:28

3-Dec-03 15:28

thanks you!Now the thing confused my head is that my web component can changed its surface when the data it bound to,but how can i make the same change apperaed in client connected with the server?

您的帮助将使我受益匪浅！

Heath Stewart4-Dec-03 3:55

Get Path & File name using OpenFileDialog

4-Dec-03 3:55

Here's an ASCII chart:

Web Browser (client) -> Request -> HTTP Server (server)
client <- Response <- server
 
Embedded Control (client) <-> DCOM/Remoting Server (server)

Notice how the embedded control can communicate BOTH ways with the DCOM or Remoting server? See, you're missing the crutial point here and you must understand this or you're really in trouble. HTTP communication is essentially one way. Yes, the browser requests information from the server and the server sends it out, but the server cannot send out information without a request from a client application.

For what you need, you are EMBEDDING a control in a Web page (which requires no refreshing of the web browser - think of it as a stand-alone appliation that just sits there) that talks directly with a DCOM or Remoting server on the server. If the client is not firewalled, the DCOM or Remoting service can make calls on the client as well. It's two-way communication.

For a web browser, if you need to refresh data, you either have to have a javascript or browser behavior fetch data behind the scenes and update the DHTML page (or an ActiveX control or Java applet doing it in the foreground), or you have to refresh the page itself either using some javascript with a timer and window.location.reload(), or use the HTTP-EQUIV="refresh" META tag with the content="timeout;url" syntax. This is all in the MSDN Library and you should read it and understand this basic concept of the Web before you venture down a page blindly. It's crucial.

Steve McLenithan22-Nov-03 1:57

22-Nov-03 1:57

I was trying to work with this example from MSDN Library to get the filename and path of a file:

if(openFileDialog.ShowDialog() == DialogResult.OK)<br />
{<br />
   System.IO.StreamReader sr = new <br />
   System.IO.StreamReader(openFileDialog.FileName);<br />
   MessageBox.Show(sr.ReadToEnd());<br />
   sr.Close();<br />
}

The problem is that when opening large files, at least 400MB it crashes the app. Is there any other way to get JUST the path and filename of large files without actually opening them?

Thanks,

// Steve McLenithan

Cluelessnes:
There are no stupid questions, but there are a lot of inquisitive idots.

Nick Parker22-Nov-03 2:04

Nick Parker

22-Nov-03 2:04

Steve McLenithan wrote:
openFileDialog.FileName

This should do it, the dialog itself doesn't actually open the file, it only provides the interface for you to select a specified file.

-Nick Parker
DeveloperNotes.com

Steve McLenithan22-Nov-03 2:12

22-Nov-03 2:12

Hmm... When I open the file. The process for the app in taskmanager quickly rises to hogging over 260MB of RAM...

// Steve McLenithan

Cluelessnes:
There are no stupid questions, but there are a lot of inquisitive idots.

leppie22-Nov-03 3:15

leppie

22-Nov-03 3:15

Thats because u are trying to dump the entire contents of the file in a message box... The example code obviously expects a one/two line text file.

leppie ::AllocCPArticle("Zee blog");
Seen on my Campus BBS: Linux is free...coz no-one wants to pay for it.

Steve McLenithan22-Nov-03 4:36

22-Nov-03 4:36

My mistake. Thanks.

// Steve McLenithan

Cluelessnes:
There are no stupid questions, but there are a lot of inquisitive idots.

Heath Stewart22-Nov-03 4:26

22-Nov-03 4:26

leppie's right - what would you expect when opening such a large file?

Instead, read the file in blocks (streaming):

StreamReader reader = new StreamReader(openFileDialog1.FileName, true);
int read = 0;
char[] buffer = new char[4096];
do
{
  read = s.Read(buffer, 0, buffer.Length);
  Console.Write(buffer);
} while (read == buffer.Length);

Notice that I also use a StreamReader. Any TextReader or TextWriter derivites are optimized for text. The boolean in the StreamReader constructor actually attempts to determine if the text is ASCII, UTF7 or 8, or Unicode. If you use a stream, you have to know / determine the encoding yourself.

The main point, however, isthat you don't keep the entire file in memory. You dump the buffer and get more. Displaying a 200 MB file will take that much memory plus more - and if you read an ASCII file into a Char array, you'll waste even more memory because .NET stores characters and strings as Unicode - thus taking two bytes per character.

Steve McLenithan22-Nov-03 4:34

Re: Icon Background Pixels

22-Nov-03 4:34

Thanks guys.

// Steve McLenithan

Cluelessnes:
There are no stupid questions, but there are a lot of inquisitive idots.

Icon Background Pixels

Tristan Rhodes22-Nov-03 1:32

Tristan Rhodes

22-Nov-03 1:32

I am importing Icons into my program to display in my list view.

While the Icons work, and the whole program mechanism is fine, I have a problem with background "noise".
Almost all of the images I import come with messy background colour around the edges that does not show up in any external bitmap or icon viewer.
The colour is not limited to black, and covers a number of shades of brown and dark grey.

This occurs both from importing icons to internal resources, and when openend from file, and persists in both Icon and Bitmap formats.

This is VERY frustrating, as it is ruining my application.

Does anyone know what causes it? And What can I do about it?

20-17 to England!
What a game...
GO JONNIE! Drop goal 20 seconds from end of extra time...

Smile | :)

Heath Stewart22-Nov-03 4:34

Re: Icon Background Pixels

22-Nov-03 4:34

On XP or 2003, right? The problem is that the icon functions get the best icon to display in Windows. Since XP introduced alpha channels on icons, you're getting the icon with the alpha channel. Unfortunately, unless you bind to common controls 6 (.NET's System.Widnows.Forms controls are just wrappers around these), alpha blending isn't performed and you see the alpha channel as a solid color.

There's a couple different things you can do:

Enable theming in your app (which binds to comctl32 version 6).
Read the icons and remove the alpha pixels. It's not as simple as it sounds, though. You have to also use an unsafe context for optimal performance. Christian Graus here on CP has several good articles about image manipulation.

As far as enabling theming in your app, if you are using .NET 1.1 call Application.EnableVisualStyles() before calling Application.Run() in your app's entry point (Main). If you aren't using .NET 1.1 or your app could run on either 1.0 or 1.1, see my article, Windows XP Visual Styles for Windows Forms[^]. You can either embed the manifest file as a Win32 resource (not a .NET embedded resource) or keep it as a separate file that is named myappname.exe.manifest (same convention as .conf files but with a different extension).

Tristan Rhodes22-Nov-03 7:17

Tristan Rhodes

22-Nov-03 7:17

Yes, XP.

Hmmm, I understand the cause, but unfortunately, I have only been programming for around a year (any serious ammount).

I'm basicaly using an arraylist to hold icons that I pull from a OpenFileDialog() to an icon list. These icons are pooled, and linked with file extentions in my archive viewer. The viewer uses the file extentions to lookup the Icon index from the list and sets the ImageIndex to that.

I don't know what Theming is, or how to remove the alpha pixels once the icons are read.

I've been deleting the alpha manualy on imported icons, but those that I pull from the dialogbox.

For now, I shall have a look at theming.

Thanks

Tris

Re: Icon Background Pixels

Heath Stewart22-Nov-03 11:21