Hi @Andre_Mark,
Good to see you back again after a while 
Your error is in the return statement in your getBalance() function…
You need to remove the assignment operator = so that it’s referencing the balance of msg.sender in the balance mapping (exactly the same as in the return statement in your addBalance function)…
Ran into this problem on the 8th lesson:
Followed along and typed the code out verbatim. However when I deploy the contract on the left toolbar, there is no lower section like on the video where I can input a number. All it shows me under “deployed contract” heading is this message: “Currently you have no contract instances to interact with”.
Is there something I might be missing?
Also when I view the terminal below it shows “creation of HelloWorld pending”
Hi @Liquidbaker89,
Are you still having this problem deploying your contract?
It could be caused by a number of issues …
If the terminal continues to show this, without any transaction receipt with a green tick confirming successful deployment, then this is something which can happen now and again with Remix, and is usually resolved by closing it in the browser, and then reopening it. I’m not sure why it happens, but it can get “stuck” once in a while.
If you still have any compiler errors in your contract code, then this will also prevent deployment. If you have Auto Compile turned on (under Compiler Configuration in the Solidity Compiler panel) then the compiler will highlight any compiler errors while you’re writing your code. It’s often easier to debug and correct errors as and when they arise, instead of waiting until you’ve finished and then clicking compile. Either way, you need to make sure that you have compiled your contract, and resolved any errors, before you deploy it.
Once your contract is successfully compiled, you need to make sure that the name of the contract you want to deploy is showing in the Contract field (just above the orange Deploy button in the Deploy & Run Transactions panel). Then you can click the orange Deploy button, the contract should deploy, and you should see it, together with the address it’s been deployed at, below Deployed Contracts. You then need to click on it to access all of the function-call buttons.
Let me know if you’re still having any problems. If you are, then post a copy of the code you’re trying to deploy as well, so I can test it in Remix myself. If you’ve already resolved this on your own, then hopefully some of the tips I’ve given you will still prove useful
Hey guys, I made a drawing to help visualize visibility (or tried to with my poor skills on Evernote). I just started so let me know if it’s wrong, but that’s what I understood from the video.
Hi @seybastiens,
This is a really good attempt at a visual representation of visibility for functions and state variables in Solidity — well done! 
I think there is only one thing missing, and one inaccuracy …
To complete the picture, I think you should add an “external front-end service” (i.e. a web3 client) e.g. Remix or the front-end of a dapp.
Only functions with public or external visibility can be called from a web3 client. But it is important to recognise that external functions can be called from a web3 client as well as from external smart contracts.
Unlike functions, state variables cannot have external visibility. So, only public state variables are directly accessible from a web3 client (via a getter which is automatically created by Solidity).
External smart contracts (i.e. other non-derived smart contracts) can call functions with public or external visibility, but they can’t call functions with internal visibility. The only “other” contracts which can call internal functions are derived contracts, because they are inherited by the derived contract and effectively act as its own private functions. This should become clearer and make more sense when you cover inheritance later in this course.
It won’t be easy to adjust your illustration for these additional points, but I hope you’re up for the challenge!
Let me know if anything is unclear, or if you have any questions
Hey Jon, thanks for your reply.
I didn’t know about your first point so I just editted the representation accordingly.
Regarding the second point, this is why I wrote in yellow “inheritance”, because some external contracts get pointed to with yellow arrows (by inheritance). And these external contracts are the ones who have the functions in internal, that’s why they are circled in purple too. I also added a grey color to differenciate derived smarts contracts from non-derived ones.
Hopefully I understood it clearly now.
Hey Seb,
That’s looking good for the external service, because it shows it has access to both public and external functions 
I have interpreted your diagram as showing where functions and state variables can be accessed from depending on their visibility.
So, the blue box shows that public functions and state variables can be accessed from anywhere: an external service, both external (non-derived) and derived smart contracts, and from within the same smart contract 
The green box shows that private functions and state variables can only be accessed from within the same smart contract
The purple boxes show that internal functions can be accessed from within the same smart contract and any derived contracts but that internal state variables can only be accessed from within the same contract. However, as with internal functions, internal state variables can also be accessed from within derived contracts, so I think your original diagram was more accurate here (without the dotted blue line to exclude internal state variables).
Finally, I interpret the pink/brown border in the latest version of your diagram as showing that external functions can be accessed from an external service from external (non-derived) contracts but also from within any derived contracts i.e. from within any other contract. This last part isn’t true. When a derived contract is compiled, all of the inherited functionality from its base/parent contract is included within one set of byte code, which is then deployed as a single contract at a single Ethereum address. So, when the derived contract is deployed, any external functions inherited from its parent contract will behave as if they are its own. And as a contract’s own external functions cannot be accessed from within itself, neither can a derived contract access any external functions which it inherits.
So, I think the derived contracts in your diagram shouldn’t be included within the pink/brown border, so that it only encloses the external service and external (non-derived) contracts, because these are the only places where external functions can be called from.
A couple of points to clarify here …
As I mentioned before, I think this level of detail regarding internal and external visibility will become clearer, and make more sense to you, when you reach the inheritance section of the course. So, you may want to come back and make the modifications later on.
At this early stage, though, you’ve done a great job!
Just let me know if you have any more questions 
Thanks a lot for helping me improve it.
Yes this is exactly the purpose of the diagram, you said it very nicely & clearly :
I didn’t know about this part. How is that ? I don’t get it.
“Access within itself” means that the function is part of the smart contract, but its type switched from external to private ?
And also you mean that when the smart contract is “derived”, all its functions (which are external, public, private or internal) will become private on the derived smart contract. Right ?
So we cannot access (copy or/and just see what is inside) the private functions of a smart contract that is not ours, correct?
I tried to readapt it again from what I understood from this.!
Hi @seybastiens,
Sorry for the delay in getting back to you on this!
No … it means that if a contract contains a function with external visibility, then it cannot be called from within any other function within that same contract e.g.
// SPDX-License-Identifier: UNLICENSED
pragma solidity 0.7.5;
contract Example {
string public message;
function inputMessage(string memory _message) external {
setMessage_A(_message); // COMPILER ERROR
setMessage_B(_message);
}
// EXTERNAL visibility, so CANNOT be accessed/called by inputMessage()
function setMessage_A(string memory _message) external {
message = _message;
}
// PRIVATE visibility, so CAN be accessed/called by inputMessage()
function setMessage_B(string memory _message) private {
message = _message;
}
}
A function with external visibility also cannot be called from within any functions in a derived contract e.g.
// SPDX-License-Identifier: UNLICENSED
pragma solidity 0.7.5;
contract Base {
string public message;
// EXTERNAL visibility, so CANNOT be accessed/called by inputMessage()
function setMessage_A(string memory _message) external {
message = _message;
}
// PRIVATE visibility, so CANNOT be accessed/called by inputMessage()
function setMessage_B(string memory _message) private {
message = _message;
}
// INTERNAL visibility, so CAN be accessed/called by inputMessage()
function setMessage_C(string memory _message) internal {
message = _message;
}
}
contract Derived is Base {
function inputMessage(string memory _message) external {
setMessage_A(_message); // COMPILER ERROR
setMessage_B(_message); // COMPILER ERROR
setMessage_C(_message);
}
}
If we use this 2nd example to illustrate what I meant in my previous post, then when we deploy Derived…
message , and the external and internal functions setMessage_A and setMessage_C
setMessage_B
So, we are only deploying one contract (Derived) which contains one set of compiled bytecode representing the whole of Derived and the functionality inherited from Base i.e.
message; andinputMessage , setMessage_A and setMessage_C
In other words, the functionality of the external function setMessage_A , although written in Base, will be included within the bytecode deployed as Derived. But in this case, whether you think of this function as being in Derived or in Base, it’s accessibility is the same: it can be called from an external service, or from an external (separately deployed) contract, but NOT from within a function in the same contract deployed as Derived.
So, no, I didn’t mean this. The visibility of any contract’s functions doesn’t change. Hopefully, my additional explanation above has now made this clearer, and explains this better.
Yes … this is essentially correct. But rather than thinking in terms of “we” and “our” etc., you need to think of accessibility in terms of “where from” …
A) Externally (from outside the deployed contract)
1. From an external service.
2. From within a function in an external contract (a contract which has been separately deployed).
B) Internally (from inside the same deployed contract)
1. From a function written in the same contract as the state variable being accessed or the function being called.
2. From a function written in a derived contract which inherits the state variable being accessed or the function being called.
Functions and state variables with public visibility can be accessed from anywhere (A1, A2, B1 and B2).
Functions and state variables with private visibility can only be accessed from B1.
Functions with external visibility can be accessed from anywhere outside the deployed contract (A1 and A2).
Functions and state variables with internal visibility can be accessed from anywhere inside the same deployed contract (B1 and B2).
So, in terms of your diagram …
If, as I think you’ve confirmed, the thick, coloured boxes/borders indicate where the functions and state variables in OurSC can be called/accessed from, then all of these now enclose the correct locations …
Functions and state variables with public visibility can be accessed from anywhere (blue box).
Functions and state variables with private visibility can only be accessed from inside the same deployed contract AND where they are also written in that same contract and not inherited (green box).
Functions with external visibility can be accessed from anywhere outside a deployed contract, whether the deployed contract is a derived contract or not (red border).
Functions and state variables with internal visibility can be accessed from anywhere inside the same deployed contract, whether the deployed contract is a derived contract or not (purple border).
I think the only things you now need to correct are …
public and internal visibility being inherited by derived contracts, external functions (red) are also inherited. However, only the inherited public and internal functions and state variables from the base contract are accessible from within the derived contract’s functions. So you could change this note to something like …Inherited functions/state variables accessible from within the derived contract itself
Derived smart contracts
external (red) and public (blue) functions from your external contracts because this is confusing. Otherwise, you will need to clarify what this means with another note e.g.Functions which can be called externally (from an external service or contract)
… but this is already shown by the the blue and red borders.
Wow! That was a long post! 
But I hope it’s been helpful, and I’ve answered your questions. Let me know if you have any more
Amazing thanks for your time Jon,
I think that now everything is clear is my head and on the diagram too.
Here is the last version with the corrections.
So derived contracts will inherite public, internal and external functions / state variables (blue, purple and red dots), but they can only access the public and internal ones from the deployed smart contract (so only within the blue and purple thick lines.
I would like to know how to add uint values with commas.
For example: if I want to add the weight of a person inside a data type “person”, Id like to be able to enter manually “90,5” (as in 90kilos and 500 grams)
what type of data type do I have to choose, is unit correct? and when I enter its value on remix, how can I make remix understand that the comma I add belongs to the number of 90,5 and is not defining another value type (because commas are used to separate value types )
Great question @JPLaclau!
… and it’s good to see you back here in the forum
Basically, you’re asking if we can write numbers with decimal places in Solidity…
It depends on the country whether a decimal point (full stop or period character) or a decimal comma is used to separate the “whole” part of the number (integer) from its decimal places (fractional part) e.g. the decimal point is used in the UK and the US, whereas the decimal comma is used in Spain and France.
However, Solidity doesn’t allow us to express numbers with decimal places (fractional parts), so we can’t use a decimal point or comma. All numbers must be integers (whole numbers): either unsigned (uint) or signed (int). Unsigned integers can only be positive (including 0), whereas signed integers can be positive or negative.
When we code a smart contract using Solidity, if we need to express number values of things like currencies, weights, measurements etc., which use a hierarchy of units (e.g. kilometer, meter, centimeter, millimeter), then this isn’t actually a problem, as long as we represent, calculate, manipulate, process and store all of these numbers in units which avoid having to use decimal places.
So, if the smallest unit of weight your smart contract needs to handle is grams (not milligrams), then the best solution here would probably be to work with these number values in grams e.g.
90500 // 90,5 kg (or 90.5 kg)
100000 // 100 kg
64375 // 64,375 kg (or 64.375 kg)
If you want these values to be displayed to, and input by, the end user in kilograms, with the grams expressed as decimal places (fractions of a kilogram), then you can perform the to/from conversions, together with the appropriate formatting with commas, full stops, “kg” etc., in your frontend code using JavaScript.
As Wei is the smallest unit of the Ethereum network’s native cryptocurrency, Ether, when working with Ether values in our smart-contract Solidity code, we express these values in units of Wei e.g.
4500000000000000000
// 4500000000000000000 Wei = 4500000000 Gwei = 4.5 Ether
5750000000000000
// 5750000000000000 Wei = 5750000 Gwei = 0.00575 Ether
333225
// 333225 Wei = 0.000333225 Gwei = 0.000000000000333225 Ether
1
// 1 Wei = 0.000000001 Gwei = 0.000000000000000001 Ether
However, Solidity syntax does also include the suffixes ether and gwei, which provide us with a useful shorthand, and do allow numbers to be written with fractional parts using a decimal point (but not a decimal comma). For example, 1 Ether can be expressed using the following 3 alternatives…
1000000000000000000
1000000000 gwei // gwei keyword equivalent to: * 1000000000 (9 zeros)
1 ether // ether keyword equivalent to: * 1000000000000000000 (18 zeros)
… and the previous examples could also be written in Solidity as follows …
4500000000000000000 // or
4500000000 gwei // or
4.5 ether
5750000000000000 // or
5750000 gwei // or
0.00575 ether
333225 // or
0.000333225 gwei // or
0.000000000000333225 ether
The suffix wei is also available, but this would only seem to be worth using in situations where there could be a risk of confusion, because, for example, the following 2 alternatives are both valid Solidity code for 0.05 Gwei …
50000000 wei // or
50000000
Here is a link to the relevant section in the Solidity documentation about these keywords …
https://docs.soliditylang.org/en/latest/units-and-global-variables.html#ether-units
In terms of your other questions …
Number values in our Solidity code which represent Ether values need to be defined as unsigned integers (uint data type). In fact, you would only want to use signed integers (int data type) for other units of currency, weight, measurement etc. (such as your kilograms/grams) when you need to be able to represent, process and store negative values within your smart contract.
So, in Remix, when you want to call a function with a number argument …
A uint function parameter will only accept an unsigned integer (a whole number comprising only of digits, with no other character types, such as full stops, or commas).
An int function parameter will only accept either a positive or negative integer (a whole number comprising only of digits, with a single, optional minus sign being the only other character allowed to precede it.
Let me know if anything is unclear, or if you have any further questions
Why this function should be pure? (it is working with view too)
It is not clear in the lesson.
function count(int number) public pure return(int) {
for(int i = 0 ; i < 10 ; i++) {
number++;
}
return number;
}
}
Hi @RasHam,
Yes … your function will still work when defined with any of the four function types …
However, when developing smart contracts, it is important to reduce security risk by only permitting each function to access and change what it needs to. So, because your function not only doesn’t need to change any data stored in a state variable, but also doesn’t need to access and read any data stored in a state variable, your function should be defined with the most restrictive function type: pure.
The compiler helps us to ensure that we define a function as the most restrictive data type for the operations it needs to perform. If you define your function as view, the compiler will generate an orange warning for the line with the function header containing the keyword. The warning message will tell you that the more restrictive keyword pure should be used instead of view. The compiler will also throw a red error if the function type has been defined as too restrictive for the operations it needs to perform, and the error message will tell you which keyword is the most appropriate.
Compiler errors will prevent your code from compiling and your contract from being deployed. But you can choose to ignore compiler warnings, because they won’t prevent your contract from being deployed. However, the compiler generates warnings to highlight specific issues and risk factors, and so they should only be ignored if you fully understand these issues and potential risks, and if you are certain that in your particular use case they can be safely disregarded.
By the way, your returns keyword is missing an ‘s’ in the function header. It should be …
returns(int)
… otherwise it won’t compile at all.
I hope that clarifies things. But just let me know if you have any further questions
thank you very much, I am 100% clarified. I am getting the habbit of return and returns yet.
What are the examples of usages regarding to several data types of key in a dictionary?
I am familiar with mapping unique key in string but not in other data types.
I love the old school blackboard.
Hello folks !
Im new to the course and im trying to deploy a code from the Control Flow lesson,
and the code runs without any bugs, but the decoded output I always get is - .
Any idea how to get the decoded output instead of blank statement ?
ParserError: Invalid SPDX license identifier.
What does this error mean ?