That's what I was expecting. If you can separate the two actions, maybe a double click would open without building.benryves wrote:The "Build" menu option/verb is carried over from when it would just build the project and exit immediately (or remain open if there were any errors).
Brass 3.0.0.0 Beta 13
Ah very nice, I didn't know you modify the context menu items with registry alone.
- benryves
- Maxcoderz Staff
- Posts: 3087
- Joined: Thu 16 Dec, 2004 10:06 pm
- Location: Croydon, England
- Contact:
Certain verbs (open, edit, print - not sure if they have to be lowercase or not) will also be automatically translated into the OS language for you.
I don't actually know how you detect which verb was used to run an application via the Win32 API, though. (It's part of the Process class in the .NET environment).
I don't actually know how you detect which verb was used to run an application via the Win32 API, though. (It's part of the Process class in the .NET environment).
- driesguldolf
- Extreme Poster
- Posts: 395
- Joined: Thu 17 May, 2007 4:49 pm
- Location: $4080
- Contact:
[inserts last 2 posts from here]
Or do you mean it's just for stylish code?![Smile :)](./images/smilies/grayscale_smile.gif)
EDIT:
apparently labels aren't cooperating a lot, don't they?
Gives a duplicate label error (label x.y already exists)
driesguldolf wrote:Now I'm confused, in which thread am I supposed to post bug reports now?
anyway, not really a bug, just an inconvenience.
If you forget an end quote (of a string) then brass thinks the next lines are all part of the string.
This might be intended, but a warning would be better I think.Also while writing this I found out that brass is too attached to shortcut keys, ctrl-c doesn't work, neither does right clicking. Drag and drop does work however.Code: Select all
Duplicate label 'bytes'. .include "XBall\\engine.inc .echoln "XBall: ", $-start_of_code, " bytes (engine: ", engine.size, " bytes)." .endmodule ;==================== ; End of file ;====================
Suggestion: It might be interesting if brass gave a warning if a local label stretches multiple files.
Something like this:Is perfectly valid and could cause some severe headachesFile "file1.txt"File "file2.txt"Code: Select all
- jp +
Code: Select all
+ jp -
(same for modules/sections etc.)
More on that:gives an error... I haven't tested it in an expression however. (brass 3 doesn't like the {})Code: Select all
- jp {-}
EDIT: the forum also formats text wrong in quotes if that quote includes code
I don't see how enters in strings can be useful? "\n" does the job as well.benryves wrote:You should really use the other thread for bug reports (this is a pretty much a dead thread).
Strings constants continuing past the end of the line is by design, maybe I could C#-ise this capability with an @ sign in front of the string, eg:
I disabled all shortcut keys in IE again, I think I need to reenable them again and hopefully it'll work this time..!Code: Select all
.db @"This is a multiline string", 0
Triggering an event when you leave the current file (when assembling) could be used to detect cross-file problems I suppose. Reusable labels could be an especially big problem.
Or do you mean it's just for stylish code?
![Smile :)](./images/smilies/grayscale_smile.gif)
EDIT:
apparently labels aren't cooperating a lot, don't they?
Code: Select all
.module x
y
.module z
y
.endmodule
.endmodule
- benryves
- Maxcoderz Staff
- Posts: 3087
- Joined: Thu 16 Dec, 2004 10:06 pm
- Location: Croydon, England
- Contact:
As I'm using the assembler pretty heavily for my current project I'm fixing some of the bugs as I'm going (though not on the ones others have reported just yet, sorry, only ones I need - selfish, I know).
Due to the hacky and erratic way I'm doing this I haven't released any new binaries; for the moment you'll need to check out and build the source yourself.
This isn't really intended as an official update, just a heads-up that if you are really desperate to have some of the bugs fixed then you can update manually. I will release a proper binary package at some point in the future containing these minor fixes and the ones other have reported.
Due to the hacky and erratic way I'm doing this I haven't released any new binaries; for the moment you'll need to check out and build the source yourself.
This isn't really intended as an official update, just a heads-up that if you are really desperate to have some of the bugs fixed then you can update manually. I will release a proper binary package at some point in the future containing these minor fixes and the ones other have reported.
- driesguldolf
- Extreme Poster
- Posts: 395
- Joined: Thu 17 May, 2007 4:49 pm
- Location: $4080
- Contact:
- driesguldolf
- Extreme Poster
- Posts: 395
- Joined: Thu 17 May, 2007 4:49 pm
- Location: $4080
- Contact:
- driesguldolf
- Extreme Poster
- Posts: 395
- Joined: Thu 17 May, 2007 4:49 pm
- Location: $4080
- Contact:
Ah, that explains everythingtr1p1ea wrote:There is a known emulator bug (both pindurti and wabbit) that will cause a defrag when you use variable creation calls (to make appvars etc).
Have you tested it on hardware?
![Smile :)](./images/smilies/grayscale_smile.gif)
A long time ago I had the same problem where pti would delete the app after while (I never got around to check how many times it took) but it would work just fine on hardware.
Thanks for clearing that up
![Smile :)](./images/smilies/grayscale_smile.gif)
- calc84maniac
- Regular Member
- Posts: 112
- Joined: Wed 18 Oct, 2006 7:34 pm
- Location: The ex-planet Pluto
- Contact:
If I remember correctly, you have to reset the RAM to make new apps show up. I just use Wabbitemu now, though.benryves wrote:I can't install apps at all on the later versions of PindurTI (it seems to install but doesn't appear on the list of apps). I use one of the old builds with two screens instead, where they install fine.
![Razz :P](./images/smilies/grayscale_grin.gif)
~calc84maniac has spoken.
Projects:
F-Zero 83+
Project M (Super Mario for 83+)
Projects:
F-Zero 83+
Project M (Super Mario for 83+)
- driesguldolf
- Extreme Poster
- Posts: 395
- Joined: Thu 17 May, 2007 4:49 pm
- Location: $4080
- Contact:
- driesguldolf
- Extreme Poster
- Posts: 395
- Joined: Thu 17 May, 2007 4:49 pm
- Location: $4080
- Contact:
Nah, it's more likely pti is correctly handling the corrupted hex file.
Even TIConnect likes my app
(I was able to successfully send it to a ti84+ and run it without problems (besides the bugs that were also happening in pti))
EDIT:
Of course I forgot something when I replaced it with the correct content:
(I forgot to replace "Main.asm" with the correct source file)
![Image](http://img391.imageshack.us/img391/2742/lolwuthl0.png)
That's... Nice![Razz :P](./images/smilies/grayscale_grin.gif)
Even TIConnect likes my app
![Mr. Green :mrgreen:](./images/smilies/icon_mrgreen.gif)
EDIT:
Erm, it appears I was mistaken. This was the .brassproj I was using:PM by benryves wrote:Ah, that makes sense! You've got the .appheader directive in your own source, which means that the header gets written twice (as .appheader is also defined in the template). That would probably explain the two records at the start of the file that both point to the same address ($4000).
All you need in your own source is .page 0, followed by code.
Code: Select all
<?xml version="1.0" encoding="utf-8" ?>
<brassproject version="0">
<plugins>
<collection source="Core.dll" />
<collection source="Z80.dll" />
<collection source="TiCalc.dll" />
</plugins>
<input source="puzzact.asm" assembler="z80" />
<output destination="puzzact.8xk" writer="ti8xapp" />
</brassproject>
(I forgot to replace "Main.asm" with the correct source file)
![Image](http://img391.imageshack.us/img391/2742/lolwuthl0.png)
That's... Nice
![Razz :P](./images/smilies/grayscale_grin.gif)