|
hi evryone
how i can show any massage before the main form is load ?
(i work in WinCE)
thank's for any help
|
|
|
|
|
E_Gold wrote: (i work in WinCE)
Good thing you asking in the mobile[^] forums..
wait a tick...
|
|
|
|
|
E_Gold wrote: how i can show any massage before the main form is load ?
Why only show the massage? Why not give it? It would be an awesome technology - Being massaged while waiting for an application to load.
![Green Alien | [Alien]](https://www.codeproject.com/script/Forums/Images/alien.gif) Kristian Sixhoej
"You can always become better." - Tiger Woods
|
|
|
|
|
I always wonder, when cp will include a spell check. for people like me, who are not good at english. but in this case even spell check cant help you. 
|
|
|
|
|
English is not my lenguage, sorry
|
|
|
|
|
neither mine. if you read my post again, i have included myself also. I just found that post funny. thats it, dont take offence man.
|
|
|
|
|
Look in program.cs, I think you'll be able to figure out how to do this.
|
|
|
|
|
thank's for the help, i have the Main form that load database and fill comboBox whit database. it take for 10-15 second. i need that in this time will be any message. how can i do it ? (i dont want MessageBox)
|
|
|
|
|
What you describe is named a "splash screen". There are lot of examples on this site describing how to do this.
|
|
|
|
|
Form1_Load(object sender, EventArgs e)
{
MessageBox.Show("My Message");
}
TVMU^P[[IGIOQHG^JSH`A#@`RFJ\c^JPL>;"[,*/|+&WLEZGc`AFXc!L
%^]*IRXD#@GKCQ`R\^SF_WcHbORY87֦ʻ6ϣN8ȤBcRAV\Z^&SU~%CSWQ@#2
W_AD`EPABIKRDFVS)EVLQK)JKSQXUFYK[M`UKs*$GwU#(QDXBER@CBN%
Rs0~53%eYrd8mt^7Z6]iTF+(EWfJ9zaK-iTV.C\y<pjxsg-b$f4ia>
--------------------------------------------------------
128 bit encrypted signature, crack if you can
|
|
|
|
|
so you want to show a Splash screen.
create a form with message / image on it. now put a Timer and set the interval to 10000-15000, and on a Tick() Event just do this.hide(); and on the Load() of that form call (create instance and .Show() method) your Main Form.
and dont forgot to set that spalsh form to startup form instead of main form.
Done. so your splash form will be displayed while your main form is loading in background.
|
|
|
|
|
I have seen in many cases developers are creating property like this.
private int _UserID
public int UserID
{
get { return _UserID; }
set { _UserID = value; }
}
where no calculation or processing occurs at all in any way.
It is a better way?
In this case, we can simply use a public variable.
Which is better. Please comment.
Thanks.
|
|
|
|
|
There is no "better".
You'll get diff'rent answers depending on personal preference. One can argue that properties can be accessed through reflection, whereas a public variable can't. Some argue that it brings overhead in extra CPU-cycles, whilst this is hardly noticeble, especially in VB.NET applications that are doing heavy COM-interop 
I are troll
|
|
|
|
|
Eddy Vluggen wrote: a public variable can't
Ummm... what?
|
|
|
|
|
..be accessed through reflection?
Or should that be "I don't know how to access a public variable"?
I are troll
|
|
|
|
|
Eddy Vluggen wrote: Or should that be "I don't know how to access a public variable"?
Yeah, maybe.
|
|
|
|
|
It's just a matter of what book you read / what your teacher instructed you. All academic's I've learned under always preached interface and design patterns before they showed you any code, so I for one always use Properties. Yes, like the other replier said, CPU cycles, but with today's hardware, what's a few cycles? I can't imagine using public variables anymore, whenever I do I hear my first Java 1 teachers' voice behind me saying 'getters and setters, getters and setters...'
|
|
|
|
|
This can quickly become an emotive issue, with developers having strong opinions on both sides. My considered opinion - if your property only serves to set a private field there's no reason to have it - some developers will shout that this breaks encapsulation, but get them to try and quantify why and they'll not be able to give you a satisfactory answer.
Saying that, I use properties almost all the time - the reason being that I generally have my properties do more than just set a field. In a lot of cases, my classes implement INotifyPropertyChanged, which you can use to raise an event when the property itself changes, so you can see changes reflected when using two-way binding. This means that my properties tend to look like this:
public class MyClass : INotifyPropertyChanged
{
public event PropertyChangedEventHandler PropertyChanged;
protected virtual void OnChange(string propertyName)
{
PropertyChangedEventHandler handler = PropertyChanged;
if (handler != null)
{
handler(this, new PropertyChangedEventArgs(propertyName);
}
}
private string _name;
public string Name
{
get
{
return _name;
}
set
{
if (_name != value)
{
_name = value;
Changed("Name");
}
}
}
}Then, when somebody changes the value of Name in this class, the property changed notification is raised.
|
|
|
|
|
Personally I nearly always use properties.
If a value is being made publicly available, it's normally so it can be changed externally, by using properties I get to validate the data before it reaches the field.
In cases where it's not EVER going to be changed, I do use a public field, but marked as static readonly - or const.
DaveBTW, in software, hope and pray is not a viable strategy. (Luc Pattyn)Visual Basic is not used by normal people so we're not covering it here. (Uncyclopedia)
|
|
|
|
|
DaveyM69 wrote: public field, but marked as static readonly
Yes, I do that too.
|
|
|
|
|
From an engineering perspective use Getters and Accessors. From a RAD perspective use Properties.
Need custom software developed? I do C# development and consulting all over the United States.
If you don't ask questions the answers won't stand in your way.
Doing a job is like selecting a mule, you can't choose just the front half xor the back half so when you ask me to do a job don't expect me to do it half-assed.
|
|
|
|
|
Its very useful when you gonna assign your class to PropertyGrid, Binding to Combo/List Boxes...but for me, I use both, depends on conditions
TVMU^P[[IGIOQHG^JSH`A#@`RFJ\c^JPL>;"[,*/|+&WLEZGc`AFXc!L
%^]*IRXD#@GKCQ`R\^SF_WcHbORY87֦ʻ6ϣN8ȤBcRAV\Z^&SU~%CSWQ@#2
W_AD`EPABIKRDFVS)EVLQK)JKSQXUFYK[M`UKs*$GwU#(QDXBER@CBN%
Rs0~53%eYrd8mt^7Z6]iTF+(EWfJ9zaK-iTV.C\y<pjxsg-b$f4ia>
--------------------------------------------------------
128 bit encrypted signature, crack if you can
|
|
|
|
|
A better way:
public int UserID { get; set; }
Is it better ?
The only reason (i accept) for using properties over public variables is that changing from a variable to a property breaks your interface.
http://blogs.msdn.com/abhinaba/archive/2006/04/11/572694.aspx[^]
I generally use properties unless i know for sure that i will never ever want to add logic to get/set. As it's hard to see the future i generally try to err on the side of safety.
...cmk
The idea that I can be presented with a problem, set out to logically solve it with the tools at hand, and wind up with a program that could not be legally used because someone else followed the same logical steps some years ago and filed for a patent on it is horrifying.
- John Carmack
|
|
|
|
|
Nowadays, try to use an automatic property for that.
If a field is marked readonly I don't mind making it public and foregoing a property.
I use properties when the value is settable from outside the class.
If you have a non-readonly private field with a read-only property, the user can still use Reflection to alter the value of field.
But don't let that stop you from doing the right thing.
|
|
|
|
|
I'm not 100% sure about .Net - but I do't think using a 'simple' property uses more processing than using a public variable.
However, a property is more future-prof. if you decide to make a change, and incorporate logic into your getter or setter - it's easer if you already have a getter and setter than if you have a public field. If you're using reflection, you would have to change code to change from a field to a property - and if you mix properties and fields, it can be confusing (as its not obvious which youare using, and using reflection, say to loop over the properties, will miss the fields.
I never use public fields.
The reason being, I see no real advantage of a public field over a simple public property (other than it is less typing - but I don't count that as maintenance is far more expensive than typing time), but sometimes there is advantage to using a property over a public field. Therefore, my standard is to use a property rather than a public field - always. Therefore my fields are always private (or protected) and I know that any access to them is either within that class or a derivative,or via the property.
___________________________________________
.\\axxx
(That's an 'M')
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
