|
Brian_TheLion wrote: At the moment I get 13 rows of the below text displayed.
Quite right because that is what your code is doing. Look at the line:
Console.Write("0-19)", deck1.DealCard());
It says print the string "0-19)"; the second part deck1.DealCard() returns a string but does nothing with it. The rest of the code does very little of any use.
As already suggested you should stop wasting your time on YouTube and get hold of a decent book on C#.
|
|
|
|
|
Hi Richard.
Do you think there is some code missing?
If this is the case then I may have to give up on getting this code to work unless you could suggest some extra code I could add to the existing code.
Brian
|
|
|
|
|
Quite frankly I don't think it's the best design of a card class that I have seen. Also, nearly all the code we see here that is taken code from a Youtube video, turns out to be not very well written. Youtubers tend not to be particularly skilled coders. If you want to learn C# properly then get hold of a decent book on the subject, it will be time and money far better spent.
|
|
|
|
|
Brian_TheLion wrote:
Console.Write("0-19)", deck1.DealCard());
I suspect that should be:
Console.Write("{0,-19}", deck1.DealCard()); Composite formatting | Microsoft Docs[^]
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Hi Richard.
Thanks fro the suggestion.
I did as you suggested by got an error of "Input string was not in correct format".
Brian
|
|
|
|
|
|
You were correct Richard.
When I tried the format code you offered I had left the comma out of the code and got an error
I tried
Console.Write("{0-19}", deck1.DealCard());
instead of
Console.Write("{0,-19}", deck1.DealCard());
All is working find now thanks.
Brian
|
|
|
|
|
Firstly, Return is not a C# keyword: it's case sensitive, remember - so it's return instead.
Secondly, what
return face + " of " + suit; returns depends on the type of face and suit - if they are both strings, it'll work. If face is an integer, it'll work. If it's a special class, then it'll only work if you have overridden ToString in that class.
But basically, we can't directly help you - we can't run your code in isolation and get the same results you do.
So, it's going to be up to you.
Fortunately, you have a tool available to you which will help you find out what is going on: the debugger. If you don't know how to use it then a quick Google for "Visual Studio debugger" should give you the info you need.
Put a breakpoint on the first line in the function, and run your code through the debugger. Then look at your code, and at your data and work out what should happen manually. Then single step each line checking that what you expected to happen is exactly what did. When it isn't, that's when you have a problem, and you can back-track (or run it again and look more closely) to find out why.
Sorry, but we can't do that for you - time for you to learn a new (and very, very useful) skill: debugging!
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Hi Griff.
I did try stepping through the code but with the way the program is written I can't always get exact values for some of the variables.
I have sent the complete code in hope that you might spot an error.
I posted the complete code as a reply to my first reply which I think was from yourself.
Hoping you can help
Brian
|
|
|
|
|
Brian_TheLion wrote: I did try stepping through the code but with the way the program is written I can't always get exact values for some of the variables.
Cobblers.
If you can't get "exact values" with the debugger then you are using it wrong - or not using it at all - when you run code in the debugger it is executing your code, so you get to see exactly what you code does when it is running.
If the values you see are not what you expected, then that's a problem with your code, not with the debugger - and that's what the debugger is there for, to help you find the palces where your code isn;t doing what you expected it to.
Shuffling cards is trivial: a very simple way to do it is to put all the cards in an array and use an random number generator to give you two indexes: swap the two cards in those locations. Repeat that at least 5 or 6 times the number of cards involved (52 in a normal pack, so 260 to 312) and the cards are shufffled ...
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Hi Griff.
I'll give you an example why I'm not getting enought info when debugging.
Please refer to my code that I posted a day ago .
In the line return deck[CurrentCard++], If I put on cursor on deck[CurrentCard++] up pops the message "deck1 Card_Shuffle.Deck)"
In the Console.Write line of code, if I put my cursor on deck1.DealCard() then up pops the message "deck1 Card_Shuffle.Deck).
I can't see how I can find out what is wrong by the messages I get when checking these variables in the code.
Brian
|
|
|
|
|
That's just the basic type info for what you're hovering over. When you hover over deck1 it shows the info for that object. If you want to know what "deck1[x]" is then you can highlight the whole string including the square brackets, right click and select "Quick Watch" from the context menu.
Another debugging tip is that compound statements like this
Console.Write("0-19)", deck1.DealCard());
are harder to debug. While still in the coding process it will often help to split things up into individual lines
Card card = deck1.DealCard();
Console.Write("0-19)", card);
You can now inspect "card" to see what DealCard has returned. If it looks like what you expect then you know it is the Console.Write that isn't doing what you expect. By splitting the code into two separate stages you can test them separately...you can test DealCard is doing what you want, then Console.Write. With your original code you are doing two things at once so it is harder to know which of those things is failing. Once you have your bugs ironed out and the code working, you can go back to the code in line if you wish.
The reason your Console.Write isn't working is because you are using the two param method, so the first param ("0-19)") is the "format" and the second param ("card") is the data you want to show in that format. However "0-19)" is not a proper formatting string so all you will get is that text out verbatim. A formatting string has placeholders for the values, so {0} for the first param, {1} for the second etc.
To see this in action try;
Card card = deck1.DealCard();
Console.Write("card {0} = {1} ", i, card);
|
|
|
|
|
Thanks F-ES Sitecore for the suggested changes to the code.
I finally have got this program to print out the cards. Good to make some progress.
I altered the your code to
Console.Write(card+",");
so they would print in my preferred format.
Brian
|
|
|
|
|
Hi F-ES Sitecore.
I had another look at the original and found that I had made a mistake.
Console.Write("0-19)", deck1.DealCard);
should have been
Console.Write("{0,-19}", deck1.DealCard);
I don't think a debugging the code would have lead me to the correct code but I can see your point in expanding the code over several lines.
Brian
|
|
|
|
|
Let's assume we have methods that calculates something:
public int calculateSomething1(int param)
{
int calculatedValue;
...Calculations...
return calculatedValue;
}
public int calculateSomething2(int param)
{
int calculatedValue;
...Calculations...
return calculatedValue;
}
What would be the best way to store these in a database (we can assume SQL Server)? Would it be to put the methods in separate dll:s and then insert all the bytes inside the dll into the database and then load them as dynamic dll:s in RAM? Or something else? Inserting the raw source code as varchar and then compile it in runtime is too slow.
|
|
|
|
|
What exactly are you trying to do? Code should go in your program not the database.
|
|
|
|
|
It's for register maps and register value loop-up for different products and it would be nice if only the database (not the .exe-file) needs to be updated as we add new products and registers. For example, let's assume a register called MONTH, this register would need this table to convert from an integer to a user-friendly string:
1 January
2 February
3 March
4 April
5 May
6 June
7 July
8 August
9 September
10 October
11 November
12 December
Now, let's a assume a different register called YEAR_MONTH_AND_DATE, all stored within the same integer, image how big that lookup table would be. Instead, it would be much easier to just a have method to do the conversion:
public string convertYearMonthAndDate(UInt32 yearMonthAndDate)
{
UInt16 year = (UInt16)(yearMonthAndDate >> 16);
byte month = (byte) (yearMonthAndDate >> 8);
byte date = (byte) (yearMonthAndDate >> 0);
string monthString = "";
switch (month)
{
case 1: monthString = "January"; break;
case 2: monthString = "February"; break;
case 3: monthString = "March"; break;
case 4: monthString = "April"; break;
case 5: monthString = "May"; break;
case 6: monthString = "June"; break;
case 7: monthString = "July"; break;
case 8: monthString = "August"; break;
case 9: monthString = "September"; break;
case 10: monthString = "October"; break;
case 11: monthString = "November"; break;
case 12: monthString = "December"; break;
}
return monthString + " " + date + ", " + year;
}
|
|
|
|
|
Both of those methods look broadly similar but redundant. If you store dates as proper date types in the database then you can use the standard .NET classes to get them printed in clear text.
|
|
|
|
|
|
About 40 years ago, when I was still a student, we had this database system where you could define triggers in the database for doing all sorts of integrity checks etc. on the database, independently of the application. This was a realational database, but using an extended variant of Pascal to address the tables: What would be WHERE criteria in SQL was indexing expressions in the database tables, etc. You didn't adrress the database as an external entity, but rather declared you application as an entity in the database: The databse tables were defined in a layer conceptually "outside" the program entity, encompassing it. Tables were defined using the same syntax as Pascal arrays, but being "outside" the program, they had a lifetime scope beyond the execution of the program; they looked just like other arrays, but were persistent, and had extended indexing facilities and other table operations.
This compiler was based on the classical P4 Pascal compiler. So when you compiled a database routine, the P4 code was stored in the database, available to any program using this database as an outer shell. The routines were instruction set and OS independent; the database (with its embedded routines) could be accessed from any OS or machine architecture that offered a P4 interpreter.
I believe that this project started around 1975-76, so it was quite early for this kind of architecture.
|
|
|
|
|
I have a vague recollection of someone talking about something similar to what you describe. Round about the late 1970s IIRC.
|
|
|
|
|
arnold_w wrote: Inserting the raw source code as varchar and then compile it in runtime is too slow.
Compile it on first execution (or save), save the resulting assembly in a database-blob. Could easily be timestamped, to see if the source has been altered.
Do consider that sometimes compilations fail due to errors in code.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
|
That's what I was going to suggest, but that kinda hides functionality, and if you're going to create those assemblies, why not just put them in your app?
We use them where I work, but they were implemented years ago, and I'm not even sure where the source code is.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
#realJSOP wrote: if you're going to create those assemblies, why not just put them in your app?
Because there may be many apps. You may want some functions to carry out e.g. consistency checking (beyond what you can set up in the SQL schema) regardless of which application is used.
Think of such code as belonging to the schema, not to the data.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
