|
Thanks 
|
|
|
|
|
I have MDI Parent form. I want an alawys visible MDI Child to act like a side bar with a fixed width and every new MDI child I open will occupy the remaining space only when I dock it to fill?
how can I do this?
|
|
|
|
|
jrahma wrote: how can I do this?
public class FormMyToolBox: Form
{
public FormMyToolBox (string aCaption, DockStyle aDockStyle)
{
Text = aCaption;
FormBorderStyle = FormBorderStyle.FixedToolWindow;
Dock = aDockStyle;
TopLevel = false;
Visible = true;
}
Controls.Add(new FormScriptToolBox(
"Ze ToolBox",
DockStyle.Right));
Works for me under Mono. Specifying the maximum or minimum width is done using the appropriate properties[^].
Bastard Programmer from Hell 
if you can't read my code, try converting it here[^]
|
|
|
|
|
sorry this is duplicate post...
kindly delete...
thanks...
|
|
|
|
|
using server client desktop application,
All clients insert and update my database (which is attached to sql server 2008).
And I have a Grid control on a Windows Form which need to be updated automatically
without user intervention.
--(I mean user will see the grid getting new records)--
|
|
|
|
|
Your Windows Form should perhaps have a background timer which checks periodically for changes to the applicable data and updates the grid when changes are found.
I wasn't, now I am, then I won't be anymore.
|
|
|
|
|
I agree with you timer could solve this, especially if it worked in another thread.
but i'm still looking for more generic solution.
it's highly appreciated if you try to help me again.
|
|
|
|
|
You're not going to get a "push" notification from the server, you're going to have to check from your client application under any circumstance. My personal solution if I was to do this would be to create a separate monitoring thread that would update the visible data cache in an application in the background so as not to affect the UI thread of the application. I would let the UI then check for a flag in the data cache indicating that updates were found and update itself. That way the application performance isn't adversely affected by the checking.
I wasn't, now I am, then I won't be anymore.
|
|
|
|
|
thanks for this explanation,your idea now is clear for me.
did you tried something like this before SqlDependency ?
|
|
|
|
|
I haven't used that. But it does look like a promising lead.
I wasn't, now I am, then I won't be anymore.
|
|
|
|
|
Any idea why the competition isn't using auto-updating grids with every instance of Sql Server?
It's called "bad design".
Bastard Programmer from Hell
if you can't read my code, try converting it here[^]
|
|
|
|
|
sorry, can't get your point.may you express your idea for me please.
|
|
|
|
|
Auto-updating grids are a "pain in the ass", a "bad idea".
Imagine you editing a name, and a person on the room next to you editing the same name. Imagine Google Wave. Imagine concurrency-errors and a network that nearly collapses under the extra traffic.
Unless you are building a MMO-game, you stay away from real-time updates.
Bastard Programmer from Hell
if you can't read my code, try converting it here[^]
|
|
|
|
|
|
The idea comes up from time to time, usually from a non-technician. Reason is that it's technically possible, and it sounds like a good idea. WarCraft can push updates in real-time, so why can't Sql Server?
Well, it can, but it's not a good idea. With someone editing in the grid, the entire grid would move (all rows!) when someone deletes the first record. Imagine the amount of network-data required, to keep all the clients up to date.
There are a whole lot of grids out there. Microsoft Access did not implement the feature, nor did the other grids. Ask yourself why.
Bastard Programmer from Hell
if you can't read my code, try converting it here[^]
|
|
|
|
|
thanks bro for your help, I really I appreciate your efforts.
I'll tell you how I tried to solve the problems you mentioned and you please tell me
what do think about my solutions :
* About saving two records at same time I follow the following:
- grid is only for showing data, adding and editing data in a separate form.
- I added a column with datatype of timestamp in almost all database tables.
- when I show editing form to edit a specific record,I select the timestamp for this specific record (and keep it with me in a variable).
- before I execute the update statement to update the specific record I check for the record timestamp and compare it with the timestamp variable,and if there's any changes I display message for user before saving.
* About updating data according to database changes (which occurred by other users) till now I have two choices,
-first one is timer and I dislike
-this idea,the second choice is Using SqlDependency for data change events
|
|
|
|
|
EgyptianRobot wrote: * About saving two records at same time I follow the following:
Concurrency-problems. What happens when two people edit the same record? Whose version is saved? Also keep in mind that the network-traffic and server-usage grows with the number of concurrent users.
No, I'm not going deep into the possible pitfalls; seen enough hacks that "proved" that the prototype works, but have yet to find the first real implementation.
Bastard Programmer from Hell
if you can't read my code, try converting it here[^]
|
|
|
|
|
Eddy Vluggen wrote: Also keep in mind that the network-traffic and server-usage grows with the number of concurrent users.
You are right,do you think it's better to add a refresh button above the grid?
|
|
|
|
|
EgyptianRobot wrote: You are right,do you think it's better to add a refresh button above the grid?
Most people will recognize and know what to expect from a refresh-button. It's easy to implement, so yes, that'd be my preference.
Perhaps you could try a combination of both idea's, although I can't guarantee how it will do in practice; you could give the refresh-button a visual indication if there's "a change" (keeping track of the latest change requires one timestamp, is a lot more simpeler than keeping track of every record-modification)
The visual clue would indicate that there are changes, giving the user the option to refresh if required. That way the user would still be feeling "in control", and you wouldn't need to steal focus or move around updating the selections.
If you have the time, do experiment
Bastard Programmer from Hell
if you can't read my code, try converting it here[^]
|
|
|
|
|
Eddy Vluggen wrote: Perhaps you could try a combination of both idea's
Okay,till now this is the best solution and Thanks Million for this helpful ideas.
|
|
|
|
|
My pleasure, glad I could help a bit
|
|
|
|
|
EgyptianRobot wrote: About saving two records at same time I follow the following
What business case drives your expectation that this is even possible?
What business case drives your expectation that if it did occur it would be a problem?
As an example, you have a customer screen and two users update the address field at the same time. Exactly what are the duties of the people who actually do these updates such that two of would be attempting to update the same customer at the same time? And if they did why would they be using different data?
|
|
|
|
|
I did not warn for concurrency problems on a business-case, but a technical reason. Why? Because it happens in practice; a manager "rectifying" an error in a record, while one of his worker is updating the same record. Whose values would the database be saving, and whose would be discarded?
Bastard Programmer from Hell
if you can't read my code, try converting it here[^]
|
|
|
|
|
Eddy Vluggen wrote: Why? Because it happens in practice; a manager "rectifying" an error in a
record, while one of his worker is updating the same record.
Do you have a specific industry and specific type of record/field for that example?
Moreover what is the work flow? In a standard call center, which is the only one I can think of for that example, the worker is already on another case before the manager reviews the worker updates.
|
|
|
|
|
jschell wrote: Do you have a specific industry and specific type of record/field for that example?
Yes, multiple.
jschell wrote: Moreover what is the work flow? In a standard call center, which is the only one I can think of for that example, the worker is already on another case before the manager reviews the worker updates.
Not every software-shop take the time to analyze the workflow. Imagine a MDI-form with a huge switchboard made of Buttons. Each button represents a table and opens a grid. 40 users, approx 120 tables. Administration-package, homes for the elderly. A single record might look like this;
PrimaryKey SetDataBits
123 101011110010101000100001000001100101010000001 Another example?
Same kind of "architecture" (I don't come up with them), a VB6 application that shows "Buttons" on the start-screen. Tables again, with grids. Their "workflow" consisted out of arrows drawn between the buttons. "First this table, then edit that table". Over 200 concurrent users. They discovered parameterized queries last year.
Another example?
Someone doing a MAX on a table, while another part of the computer does an insert. No, of course it ain't wrapped in a transaction. Which part of the app? Well, the logger of course 
Bastard Programmer from Hell
if you can't read my code, try converting it here[^]
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
