C# Discussion Boards - CodeProject

Re: I need code for sending SMS through asp.net in c#

10-Apr-14 0:06

It doesn't quite work like that.
We do not do your work for you.
If you want someone to write your code, you have to pay - I suggest you go to VWorker.com and ask there.

But be aware: you get what you pay for. Pay peanuts, get monkeys

Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952)
Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)

Richard MacCutchan10-Apr-14 2:23

Richard MacCutchan

10-Apr-14 2:23

Google will find you many samples.

Designer Problem

Meysam Toluie9-Apr-14 19:22

9-Apr-14 19:22

Hello everyone

For some reason I have to make my DataGridView static member in a Windows Form project.

So as it is predictable the designer window won't show to me anymore.

I want to know is there any trick to see the designer window in this situation?

OriginalGriff9-Apr-14 20:31

9-Apr-14 20:31

No.

Why static? That is a very unusual thing to do with a windows forms control, and I can't think of any reason which doesn't mean you are trying to do something else very, very wrong!

Meysam Toluie9-Apr-14 20:45

9-Apr-14 20:45

Every row in DataGridView represents information about a thread.
All threads do same job (consuming a WCF service) and any progress of thread will be show in the DataGridView immediately. As you know if I try to change cell value of DataGridView in that Method the CrossThreadException will occurs.
In this case I create a class named "shareMemory" which all progresses of a thread will save in its DataTable field;
Then the shareMemory class will update DataGridView. ShareMemory needs to access DataGridView so easiest way is to make DataGridView Static member.

OriginalGriff9-Apr-14 20:53

9-Apr-14 20:53

I thought it might be something like that! Laugh | :laugh:

No - bad idea. There is a mechanism for using UI controls from within other threads, to avoid cross threading problems: Invoke

So use that, don't try to twist things to work in a odd way!

Meysam Toluie9-Apr-14 21:30

9-Apr-14 21:30

OriginalGriff wrote:
I thought it might be something like that!

You have no idea of what I have done.

Maybe it's looks like odd but the way I have choose helped me a lot in the case of encapsulation.

OriginalGriff9-Apr-14 21:54

9-Apr-14 21:54

Only because it is a "forced solution" - it may help in one way, but it raises horrible, horrible problems in dealing with other things. Such as trying to use static controls...

Sometimes, the hardest (but best) thing to do is to say "OK, that was a silly idea", throw it away, and look at finding a more appropriate solution.

Meysam Toluie9-Apr-14 22:36

9-Apr-14 22:36

OK, that was a silly idea.

OriginalGriff9-Apr-14 22:57

9-Apr-14 22:57

Cathartic isn't it? Laugh | :laugh:

You're right, I don't know the details of your app, but the way I'd handle it from what you have said so far is to have the thread update the DGV via Invoke (the thread has the form as it's this reference, so it can access form instance variables such as controls for just this kind of reason) and pass it a row reference and some indication of which WCF service it should process. I'd then use an event in the processing class to feed the data back to a thread event handler and Invoke from there. That way the processing class can be independant of the display and you can reuse the form!
The Invoke moves the control update back onto the UI thread, so there are no cross thread exceptions.

Does that make sense?

Meysam Toluie9-Apr-14 23:23

9-Apr-14 23:23

OriginalGriff wrote:
Does that make sense?

Absolutely !

Dave Kreskowiak10-Apr-14 2:26

Dave Kreskowiak

10-Apr-14 2:26

I ran into doing something similar to this. I've got a DGV showing progress of a bunch of Tasks all doing work dependent on remote servers. Trust me, you do NOT need a static control. It does not solve the problem of cross-thread operations.

What you do need is whenever a background thread needs to update it's status it calls a method to update it's status in a table specifically made to track that information. When that method is called, it can determine if it needs to Invoke itself (put its own execution on the UI thread) to update the table and then refresh the grid that's bound to it. That's easily done with control.InvokeRequired.

A guide to posting questions on CodeProject

How to debug small programs

Dave Kreskowiak

When to read data tables?

V.10-Apr-14 22:57

10-Apr-14 22:57

In addition to what Griff said: Gather the information of the threads in an object and then pass that object to the UI datagridview (which is not static).

V.

(MQOTD rules and previous solutions)

Shady George9-Apr-14 11:26

Shady George

9-Apr-14 11:26

I’m writing an exam management program for a high school, using a remote SQL Server database. In the project, I access the database quite often, to get lists of student names, subjects, sets etc. The student (about 2200 records), Teacher (about 50 records) and subject (20 records) tables contents change very infrequently, I was wondering:

1. Would it be more efficient to read these tables at program start, and retain the information as lists<T> in memory, or should I read each table whenever the user needs it (possibly five times per session)?

2. Is SQL Server 2012 overkill for this project? I’ve thought about using SQLite in a local database, but for the life of me, I cannot get it to work. (This is the problem of working by myself, I’ve no-one to bounce ideas off).

3. Do any of you boffins have any better suggestions as to how to go about this?

I’m putting this in the C# forum, as that’s the language the database will be accessed from, but if you think that it should be in the database forum, please feel free to move it. (Or tell me and I’ll re-write it there).

OriginalGriff9-Apr-14 20:29

9-Apr-14 20:29

It really all depends on what you are doing! Laugh | :laugh:

There is no "this is best" solution - or we would all just use that and the other solutions would fall by the wayside...

The SQL server SQLite decision is a case in point: Are you expecting only one person to use the information, or multiple people? If it's one person, then yes, SQL Server can be overkill. But if it's two people who need access to the DB, then a server based solution (SQL Server or MySql) is absolutely a good idea, and SQLite is a very poor decision because it will give you enormous hassles. But...Yesterday I spent ten minutes swapping one of my utility apps from SQLCE to SQL Server despite being the only person who uses it, simply because I was fed up with the low speed on start up / shut down - so it's isn't always as black and white as it seems... Laugh | :laugh:

The tables are the same: it depends what you are doing! I have systems which do it both ways: but generally if two people can change the data, then local caching becomes a problem, unless you use some SQL triggering to force an update on your application - which is not a trivial job!

So no, we can't tell you which way to go: just keep you data layer separate from your business and presentation layers so if you did chose the wrong solution, you can "undo" it as easily as possible!

Shady George9-Apr-14 22:13

Shady George

9-Apr-14 22:13

Thanks Griff, you've put into words exactly what I wanted to hear. there's about 50 teachers, and it's remotely possible that they will all be entering results at the same time. Taking your advice, I've decided to use SQL server. The project will be on separate laptops, each with 8Gb of memory (don't you just love school standardisation?), so downloading all the data at run time won't be a problem, and I will have a trigger to flag updates. Not quite figured out how to do that yet, but I'm sure it can be done.

I'm going to use Entity Framework, as my data layer, with the business and presentation layers separated as well. In fact the only problem I can see is convincing the management team that the data is actually secure, even though it is on a remote server.

OriginalGriff9-Apr-14 22:19

9-Apr-14 22:19

You're welcome!

joost.versteegen10-Apr-14 1:40

joost.versteegen

10-Apr-14 1:40

Just a thought: You could keep a table in the database with revision numbers per table (or the whole database). Cash the data and refresh when the revision number is higher then local (small query that runs every minute). When you update, delete or insert data increment the revision number. You should use stored procedures in sql server, queries are very slow.