I've never tried this, but it seems simple enough...
You could just put a panel on your form. Turn autoscroll to true and programatically add a picture box to the panel for each picture. If a picture box is off the panel scroll bars will appear (According to the panel documentation).
It may be more efficient to just draw your images to the panel rather than using the picture box, but I am not sure. If you do jsut try drawing the images you will probably have to manage the scroll bars.
I am inserting articles in a textbox. This is later displayed by id on a page. Since each article may include images etc. I need to be able to insert the html code along with the article content. How can i format my textbox so i can insert the contents into a table?
I get an error when i try to add the html tags.
error --->A potentially dangerous Request.Form value was detected from the client (txtbooktext="...LEASE:
Runtime serialization definitely won't be any help since it is tied to Types. You can either read it in as a binary stream either with your app or through some convert app (which I know you don't want to do, but there's not a lot of choices) or develop an MC++ mixed-mode assembly that can - if possible - use your original MFC classes to deserialize the stream and construct managed classes from that data, which you can then serialize using Runtime Serialization. These classes could even be defined in a C# assembly if you want to create a conversion application.
Using MC++ would definitely be much easier since you can mix native and managed code, thus easily using your original MFC classes while also using managed classes from another assembly.
The mixed mode assembly is a good idea, i'm not sure it would work for us though as we have a very large number of objects we would have to recreate, and we may end up referencing almost all of the MFC app which i know my boss won't like, but i'll certainly look into it though thanks.
Seems odd that MS didnt offer us something better than a binary stream but not quite runtime serialization?
If you want to deserialize your old MFC stream, then wouldn't that imply you plan on recreating many of these classes in C# anyway? Also, this MC++ could simply be a conversion program so that the old MFC classes aren't need to run your actual application which requires the deserialized stream.
MFC Serialization is specific to MFC while Runtime Serialization is specific to the Runtime. They work very differently and at the time MFC serialization was designed, something like XML was a pipe-dream. .NET can also use XML Serialization (more basic, but sometimes that's good) and Runtime Serialization using either the binary or SOAP formatters provided in the FCL, or any custom formatter you or someone else could create. It's a very extensible system.
The fact is that they both work very differently.
It would be possible to create, for example, an IFormatter class that could deserialize your MFC stream and maybe even stick with the same schema, but that's quite a bit of work and still requires that you handle the binary stream from your MFC app. If you upgrade to newer technology, change is inevitable or your force to design your app to the lowest common denominator - your old MFC app.
For this new application, you may wish to look at SOAP formatting using Runtime Serialization (more powerful), or simple XML Serialization. This will allow you to easily convert to something else in the future using the XML DOM or transforming it using XSLT. XML is around to stay for quite some time. While it's not always the most compact solution (see discussions on SOAP vs. Binary formatting across remote boundaries), it's definitely extensible.
The .NET application is heavily Xml based and we use Xslt heavily aswell, mainly for the reasons you have described.
The app will be structured better than our old MFC app as over the years (and programmers) its eaten way to many pies, but thinking about it more your idea of a MC++ app is probably the best option, that way we can get at MFC classes to get the data in then from the file and then convert it to an Xml doc that our new app likes, but by having it as a seperate tool we don't have to stick to the same class heirachy as the old app.
My goal: write a TreeNode class that contains another object and have the display text for the TreeNode be automatically set to some method on the object. Psuedo-ish code:
publicclass DerivedNode : System.Windows.Forms.TreeNode
public MidTierClassLib.SomeClass oObject;
public DerivedNode(MidTierClassLib.SomeClass SomeObject)
this.oObject = SomeObject;
return (this.oObject.ToString ());
Trouble is: When I add a new DerivedNode to my TreeView, the text is blank. Stepping through in the debugger shows that the get clause is never called. This suggests I am barking up the wrong tree...
Ideally, I want to be able to change properties on oObject and have the display updated automagically. I am pretty green with using TreeViews and TreeNodes (pun intended)...couldn't find anything that looked like a databinding...so any guidance would be appreciated.
Clearly that'll do it on construction. But that won't help afterwards. Sometime later when I set a property on the oObject, I want the DerivedNode's Text property to be automatically updated as a result.
I am thinking about adding an event to the oObject that it can raise whenever a change that needs to be displayed happens. That'll work but it breaks the division between mid-tier and GUI (the oObject should not explicitly tell the GUI when to do anything).
...but that's not an appealing option either... (ain't I fun to help?!?). The objects need to be able to function without the gui. For example we may need to use then in Console applications for data maintainence or to slice and dice the data in other ways through WebApps, etc, so I think I favor the event-base approach since other application can just ignore the events.
That said, do you know why the get accessor on the DerivedNode.Text property is not called when the node is displayed? That bit baffles me.
The reason the get accessor is not called is because the TreeView uses the TreeNode type. Its Text property is not virtual so the IL instruction call is used, as opposed to callvirt. Even if you hide it using the new operator, this will not work because the TreeView is using call on the actual TreeNode type. If you were to get the Text property referencing your type (DerivedNode), then your get accessor would be called.
I am on a project that is analogous to a game in which you are tasked to draw the number of students on campus as if you are looking from a helicopter. The students can disappear from the screen as they get into classes or buildings and more students can also added as they try to get to classes from outside campus.
I have tried to use the cirular buffering technique to buffer the total number of students at one moment and display the contents on the screen. Let's say that I have a timer that ticks every 100msec which then will try to paint the location of the student on campus.
But then the problem comes when the program tries to get the student objects from the buffer which is a collection of ArrayList's. It kept telling me that the index in the ArrayList that it's trying consume has changed. I couldn't think of how to get around it now. If you could point out what is wrong with my code, or suggest any other technique, it would be very appreciative.
I've thought about your suggestion before. But I think when my timer ticks every 100msec, the number of students and the variables in the Student objects will also change. So I think it wouldn't work in this case. However, if you have a game with fixed number of players or objects on the screen, fixed-size buffer would definitely work.
Multithreaded programming is extremely difficult. Even those who are consider experts at it frequently make mistakes. The producer/consumer problem isn't trivial. It is most easily solved with semaphores[^].
privateintin = 0;
privateintout = 0;
private object buffer = new object[CAPACITY];
private Semaphore full = new Semaphore(CAPACITY);
private Semaphore empty = new Semaphore(0);
private Semaphore mutex = new Semaphore(1);
object t = buffer[out];
out = (out + 1) % buffer.Length;
object t = buffer[in];
in = (in + 1) % buffer.Length;
buffer[in] = value;
Notice that this implementation isn't trivial. Furthermore, the Semaphore implementation isn't trivial either.
I think you are pointing me to the right direction. Never before I had to use this so I'm going to have to some reading. I've just read some on semaphore on MSDN. So, I think it'll take me some time to fully understand and put together a Semaphore object
It'll take some time to fully understand so be patient. Fortunately the link I provided is for a Semaphore object that has already been coded by a Microsoft employee so you shouldn't have to put one together yourself. Good luck.