|
sharpiesharpie wrote: how can i create like a beep sound, but make it play through the speakers and not the computer's internal speaker?
Is this article on a simple beep[^] what you are looking for?
|
|
|
|
|
i have Byte[]
and i want to convert it to image ( using System.Drawing )
how that can be done
thanks
|
|
|
|
|
Just a guess:
using (MemoryStream memoryStream = new MemoryStream(bytearray))
{
Image image = Image.FromStream(memoryStream);
}
"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." - Rick Cook www.troschuetz.de
|
|
|
|
|
it really works... good guess 
thanks allot
|
|
|
|
|
Hi,
I go through a collection of toolstripmenuitems and if its the correct item, i set it to be checked.
foreach (ToolStripMenuItem sortItemDropDown in sortItem.DropDownItems)
{
if (sortItemDropDown.Name.Equals(tickSortBy))
{
sortItemDropDown.Checked = true;
}
}
The problem is that the sortedItem.DropDownItems has a Seperator in it, thus i get an exception telling me i cant convert a seperator to a menuitem. Is there a work-around ?
Regards,
Gareth.
|
|
|
|
|
In the foreach loop use the common base type ToolStripItem and only cast to a ToolStripMenuItem if the current item is really a ToolStripMenuItem.
foreach (ToolStripItem sortItemDropDown in sortItem.DropDownItems)
{
if (sortItemDropDown.Name.Equals(tickSortBy) && (sortItemDropDown is ToolStripMenuItem))
{
((ToolStripMenuItem) sortItemDropDown).Checked = true;
}
}
"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." - Rick Cook www.troschuetz.de
|
|
|
|
|
|
You can check on the type of the toolstripmenuitem. For the separator this is System.Windows.Forms.ToolStripSeparator.
|
|
|
|
|
I'm not sure about your problem, but may I ask, why not use .NET remoting? Remoting is built atop sockets, yet abstracts away the underlying byte transfers, allowing you to simply call theServer.DoSomething() on the client, or call client.DoSomethingElse() from the server.
|
|
|
|
|
Hi there,
i wonder if there is a way to include the windows-explorer in your own application.
i need the abilty to show some folders with files in my app and it´s quite a lot
of work to do the stuff with the ListView control.
is there any way to include windows explorer in my app? maybe through some kind of
activex?
thanks
jkersch
|
|
|
|
|
C# File Browser[^]
"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." - Rick Cook www.troschuetz.de
|
|
|
|
|
I am implementing a custom IExtenderProvider derived class so I can dynamically set the following properties on a control:
Required (using an ErrorProvider)
Description (ToolTip)
Errors (using an ErrorProvider)
Caption
I have everything working except for the caption. Ideally, I would like to add a Label control to the form for the given UI element. I know how to draw the label text myself, but that doesn't give me any of the accessability features that I gain when using a label.
The problem I'm running in to is that I can get the label to appear at design time but not at run time. Essentially, when I detect that a new control has been added I try to add a new label control (positioned appropriately) to the parent's Controls array. This works fine at design time but at run time the Parent property of the control I'm extending is null.
I'm trying to do this using an IExtenderProvider so I don't have to create subclassed versions of the UI controls to add a caption. In case you want the background, the project I'm working on needs to allow a dynamically rendered UI based on various pieces of meta data contained in the business object. The business object can be customized by the end-user through an admin interface, so I will never know what fields will be present and what their captions should be until it is time to actually render the screen.
Has anybody done anything similar to this? I've pretty much exhausted the information available on Google, which isn't much beyond creating a simple provider.
-----------------------------
In just two days, tomorrow will be yesterday.
|
|
|
|
|
Without source, it will be pretty challenging to give you much help. Nonetheless, in reading your post my guess is that you have an obvious problem with the Parent that has nothing to do with IExtenderProvider.
You have to solve the null Parent issue (I assume) to parent your Label. Without a parent, the Label will never be drawn.
So to fix your issue, you need to build a scheme to precipitate parent from a source value somewhere.
|
|
|
|
|
mike montagne wrote: Without source, it will be pretty challenging
I completely agree. Unfortunately I'm not able to post source for this. (I am actually trying to get approval to do this as an article (or at least a simplified version) since there seems to be a need for it.)
Since I posted I stumbled across a partial answer to this problem. I am now able to get the label to persist and generally behave properly with one exception. When I first put the extender on the form and start adding labels, none of them appear on the design surface until I close the form and re-open it. I haven't tracked down the reason for this yet.
The fact that the Parent property is null at runtime is normal as far as I can tell. The other controls and extenders that I looked at also had the same problem. (I'm not 100% sure of this since it has been several days since I looked at that aspect of it, but I'm pretty sure that was the case.)
I hope to get approval to do an article based on this work for at least a LabelProvider type control soon since I am digging semi-deeply in to how the designer works and how to manipulate properties using the design-time services.
-----------------------------
In just two days, tomorrow will be yesterday.
|
|
|
|
|
Scott Dorman wrote: Since I posted I stumbled across a partial answer to this problem. I am now able to get the label to persist and generally behave properly with one exception. When I first put the extender on the form and start adding labels, none of them appear on the design surface until I close the form and re-open it. I haven't tracked down the reason for this yet.
You probably realize this... but the reason is *always* that your algorithm hasn't triggered drawing yet. It is closing the form and re-viewing/restoring it that triggers an invalidate -- which finally gets your labels to draw.
|
|
|
|
|
mike montagne wrote: You probably realize this... but the reason is *always* that your algorithm hasn't triggered drawing yet. It is closing the form and re-viewing/restoring it that triggers an invalidate -- which finally gets your labels to draw.
Yes, that is the premise I am working under. Currently, I am attempting to resolve this by calling Invalidate myself, on both the label and it's parent control but so far it isn't having an effect.
-----------------------------
In just two days, tomorrow will be yesterday.
|
|
|
|
|
Interesting... because I've had some similiar issues with a visual control project I'm currently working on. I have quite a bit of time in developing a (proprietary) scheme which ensures that drawing is performed. (Can't share it, sorry. But you can get there too.)
A related issue for instance demonstrates to my satisfaction that there are problems with compiler output. I find some overridden event handlers such as OnSizeChanged() are correctly fired. But I find others such as OnSystemColorsChanged() and OnEnabledChanged() are never fired!
OK. So we can fix OnEnabledChanged() because we can write a new Enabled property. But we can't fix OnSystemColorsChanged() because there is no way for us to detect *and* fire the outer system event.
So, I called Microsoft about this, explained these issues for about an hour, and they wanted to charge me $249 to report them... to which I replied I wouldn't give the 2 cents to report them... I'd be more inclined to initiate a class action suit if they had so little concern about fixing all these things.
That's of course another matter, and neither are the non-fired events exactly your issue. They are surrounding issues which tell us we are not working in a perfect environment. I don't believe we should simply accept these things, because if you and I are to succeed, not only do we have to do far more work than we should have to, we have to do our work to a substantially higher standard than the authors of the tools.
It's possible you have committed a relatively obvious ommission or failed to perform a responsibility. Otherwise, the challenge is devising a sound scheme which ensures your drawing is performed when it needs to be.
|
|
|
|
|
I'm not sure I will need to go to the level of developing a completely custom scheme since I'm not actually creating a new control type. It is interesting to know about the event handlers not being raised. I don't think I will encounter that problem as there are very few events that I should actually need to listen for.
I'm a little surprised that Microsoft wanted to charge for reporting the bugs.
I do completely agree with you in that we aren't working in a perfect environment. I think the problem is that a lot of people don't need to dig this deeply into these types of behaviors/development tasks so the visibility to some of these types of problems is relatively low.
-----------------------------
In just two days, tomorrow will be yesterday.
|
|
|
|
|
I was *more* than a little surprised...
Anyway... custom schemes are required when we want to dispense with the baggage given to a higher-level control which for instance supports substantially extended behavior in suspend and resume layout, by descending from a lower-level class such as Control. You are on your own then, and (as with OnSystemColorsChanged()) I found that Invalidate() will not always invoke a re-drawing, but that I could force IL to respect Invalidate() always, by ensuring that IL recognized that something *needed* to be drawn.
|
|
|
|
|
The strange thing here is that once the label is displayed (by closing/opening the form) it shows up in the designer visually, in the designer Properties window, and I can interact with it. However, there is no code present for it in the Designer.cs file. If I further customize one of the label properties directly, I do get code in the Designer.cs file. Even with no code in this file, everything still behaves correctly at run-time and design-time.
-----------------------------
In just two days, tomorrow will be yesterday.
|
|
|
|
|
Yes, that's definitely strange, because without a parent, drawing algorithms should have no idea even where to draw the control (where the coordinate system starts, etc.)
It is possible that an assumption is made, not in performing your constructor (which would perform the initial draw which is failing), but in repainting all the existing controls (which may explain the later appearance, for instance when you collapse and restore the IDE window).
What may be happening there is that the coordinate system is simply assumed to be the design window, and your control is painted *over* it. In other words, it may be painted as a separate, unparented windowed control, floating over your design surface.
|
|
|
|
|
Hmmm...I see the point you are making, but it doesn't answer the issue of the Designer.cs file not containing any code for the label control even though it is visible in the design surface and I can interact with it.
-----------------------------
In just two days, tomorrow will be yesterday.
|
|
|
|
|
No, if the control is painted *over* the window, even if it is erroneously attached to the design window's coordinate system), and if the control is dynamically assigned a parent after design time processes would normally attach it to a parent (which triggers membership to the form code body), this would engender exactly the results you report.
|
|
|
|
|
(This also means that designers are not an issue.)
|
|
|
|
|
I'm not sure, but the fact you can interact with an unparented control might too be anomalous behavior, because I believe it is the form designer's responsibility to provide your ability to interact.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
