When I use hs-hide-level, it only hides code blocks at at the current level, but leaves comment blocks at the same level open. For example, if I take the following un-folded code:
top level code {
/* Level 2
* Multi-line
* Comment
*/
level 2 code block {
Code inside
level 2
block
}
}
And I use the hs-hide-level inside the top-level block, I will get
top level code {
/* Level 2
* Multi-line
* Comment
*/
level 2 code block { ... }
}
but I want
top level code {
/* Level 2 ...
level 2 code block {...}
}
I don't know if this feature only appeared since the question was asked, but there is the option hs-hide-comments-when-hiding-all, which according to the documentation does this:
Hide the comments too when you do an hs-hide-all.
This does not answer your question directly, but it might help nevertheless.
You can use library hide-comnt.el to hide only comments.
The description is here.
You can hide comments interactively or using Lisp macro with-comments-hidden. The effect of both is controlled by option ignore-comments-flag, which gives you additional control over the behavior.
Command hide/show-comments acts on the active region, or the whole buffer if the region is not active.
Related
Goal
I'm trying to set a PCROP area on my STM32H743VI microcontroller, but I'm getting the error code HAL_FLASH_ERROR_OB_CHANGE when executing HAL_FLASH_OB_Launch() and my PCROP area is not set.
The relevant part of the code I'm using should be the following sections
My code
#include "stm32h7xx_hal.h"
FLASH_OBProgramInitTypeDef OBInit;
HAL_FLASHEx_OBGetConfig(&OBInit);
HAL_FLASH_Unlock();
HAL_FLASH_OB_Unlock();
// program OB
OBInit.OptionType = OPTIONBYTE_PCROP;
OBInit.PCROPStartAddr = 0x8030000;
OBInit.PCROPEndAddr = 0x8031000;
OBInit.PCROPConfig = OB_PCROP_RDP_ERASE;
OBInit.Banks = FLASH_BANK_1; // (1, 2 oder BOTH)
HAL_FLASHEx_OBProgram(&OBInit);
/* write Option Bytes */
if (HAL_FLASH_OB_Launch() != HAL_OK) {
// Error handling
while (1)
{
}
}
HAL_FLASH_OB_Lock();
HAL_FLASH_Lock();
The code is mostly inspired by the youtube video "Security Part3 - STM32 Security features - 07 - PCROP lab" (by STMicroelectronics) and the working code I have to change RDP level.
Setup
My secret function is in the expected address range, I did that by adding the memory area in the Flash.Id File
MEMORY
{
[...]
PCROP (x) : ORIGIN = 0x08030000, LENGTH = 16K
}
and putting the function file into the section accordingly
SECTIONS
{
[...]
.PCROPed :
{
. = ALIGN(4);
*led_blinking.o (.text .text*)
. = ALIGN(4);
} > PCROP
[...]
}
I set the flag -mslow-flash-data for the file I'm keeping my secret function in. I did this without really understanding why, following the tutorial in the video (see above).
What I tried
I debugged my program with my J-Trace Debugger and it seems like I'm doing the Option byte modification sequence described in the STM32H743/753 reference manual (p. 159) succesfully.
Securing an entire Flashpage (start 0x080020000, end 0x0803FFFF) didn't work either, even though I did not expect it to make a difference.
I also tried the other option for PCROPConfig, namely the OB_PCROP_RDP_NOT_ERASE option.
HAL_FLASHEx_OBProgram(&OBInit) works as intended and the ObInit Configuration is set correctly into the _FLASH->PRAR_PRG1 register. For my code the content of the register is 0x80880080
I did disconnect and reconnect the microcontroller from power and debugger in case I did not POR correctly.
I checked the errata sheet, but there is no errata which would be applicable to my problem.
EDIT
I changed the area which is protected by PCROP in the My code section.
I did this, since my code is generally functional and I found out it's not a good idea to protect an area in the first flash page!
Hmm, the code looks good so far.
Are you sure PCROP is disabled before setting it again?
Check if PRAR_CUR1 is not set from somewhere else. PCROP will raise a failure when trying to set although it is set.
EDIT: As it turns out, the grid does not support unbound mode in MultiRecordView layout.
I will try to ask this question a different way since my last one was downvoted without comment, so I don't know what the downvoter was objecting to.
I've worked quite a lot with the DevExpress VerticalGrid in unbound mode in SingleRecordView. We use it in all of our desktop applications that involve lots of data-entry. All data-entry forms are consistent in look-and-feel and so user training is minimal. I think it is a great control.
However, I don't understand how to use it in unbound mode in MultiRecordView layout. I cannot even figure out how to populate the unbound grid with the data for several records. In SingleRecord layout, I use the RowsIterator to move data from my data object in memory into the corresponding row/cell in the VerticalGrid's single record.
But in MultiRecordView layout, I can't figure out how to add the second record and the third record, etc etc, and position the current record pointer so that the RowsIterator is working with the rows of the correct record.
A small code snippet, showing how to move the current record pointer when adding the second and subsequent records in MultiRecordView, would be very helpful.
I've tried AddNewRecord() and setting the FocusedRecord but without success:
for (int i = 0; i < MyTable.Rows.Count; i++)
{
vGridControl1.AddNewRecord();
vGridControl1.FocusedRecord = i;
vGridControl1.RowsIterator.DoOperation(new DataPuller(MyTable.Rows[i]));
}
and here's a relevant snippet from my DataPuller object:
public override void Execute(DevExpress.XtraVerticalGrid.Rows.BaseRow brow)
{
//<snip>
if (brow is DevExpress.XtraVerticalGrid.Rows.EditorRow)
{
string fieldname = brow.Properties.FieldName;
if (table.Columns.Contains(fieldname))
{
brow.Properties.Value = (table[fieldname] == DBNull.Value) ? null : table[fieldname];
}
}
//<snip>
}
The vertical grid doesn't support unbound mode when in MultiRecordView layout.
In Progress 11.3.2 (Developer Studio 3.7 - Eclipse 3.8.2), not using dot net at all:
How do you switch the focus to another window/application/w file?
In windows 7/8 the order of what window that is focused acts a bit different than before and does not always show the window you want to have over all the other apps.
If you have 3 windows open, and close the 3rd one and want to focus on the second one that was minimized, the first one get focus instead.
You set it to normal with WINDOW-STATE = WINDOW-NORMAL. But how to focus on it too?
If you run the secondary windows persistent you can do something like this:
In calling window:
/* In definitions */
DEFINE VARIABLE ghSecondWindow AS HANDLE NO-UNDO.
/* In a trigger */
RUN secondWindow.w PERSISTENT SET ghSecondWindow.
/* Whenever you want to shift focus */
RUN setFocus IN ghSecondWindow.
In "SecondWindow":
PROCEDURE setFocus:
/* Replace FILL-IN-1 with any widget that can gain focus */
APPLY "ENTRY" TO FILL-IN-1 IN FRAME {&FRAME-NAME}.
END PROCEDURE.
If however you are not running persistent windows you can still achieve this by walking the widget trees, first of the current window and then of the second window (once you've localized it).
Quick and ugly code to put in the calling window wherever you want the focus to shift. This might not suit your needs exactly so it might require some rewriting. Also error checking is pretty much not here and dealing with possible eternal loops without error checking is not really best practice:
DEFINE VARIABLE hWin AS HANDLE NO-UNDO.
DEFINE VARIABLE hWidget AS HANDLE NO-UNDO.
/* Get the first child (widget) of the session */
ASSIGN
hWin = SESSION:FIRST-CHILD.
/* Loop through all widgets in the session */
loop:
DO WHILE VALID-HANDLE(hWin):
/* We've identified the correct Window! */
IF hWin:TYPE = "WINDOW" AND hWin:TITLE = "Secondary Window" THEN DO:
/* ** Very Ugly** this could use better error checking etc! */
/* Get the second field-group of the window */
/* This will depend on your layout with different frames etc */
/* What we really have is WINDOW:DEFAULT-FRAME:FIELD-GROUP:FIELD-GROUP */
/* Field groups are really only present in the widget tree - they lack visual */
/* representation */
/* Read about field-groups in the online help! */
ASSIGN
hWidget = hWin:FIRST-CHILD:FIRST-CHILD:FIRST-CHILD.
/* Loop through all widgets of the field-group */
DO WHILE VALID-HANDLE(hWidget).
/* We've found the correct fill-in, give it focus */
IF hWidget:TYPE = "FILL-IN" AND hWidget:LABEL = "Fill 1" THEN DO:
APPLY "ENTRY" TO hWidget.
LEAVE loop.
END.
/* Next window of the correct window */
hWidget = hWidget:NEXT-SIBLING.
END.
END.
/* Next widget of the session */
hWin = hWin:NEXT-SIBLING.
END.
You could also do the "widget tree walk" recursively if you feel like it!
I have been googling from last couple of hours for finding that is there any way to clear NSLog output using code or not?
Like we have clrscr() in c. So if we are trying to print something which we want to focus most and there is lots of log printin there we can put that code there and get keep our desire log on top for easy searching. This can be done by putting breakpoint on my NSLog line and than click on clear console. but question is is there a way to achive this programatically?
I found few question on stack overflow but I din't satisfied with answer like this is saying that I can disable log for release mode etc.
Or I can use DLog, ALog or ULog as requirement but my question is different..
Any one can help me in this?
Thanks in advance :)
You can use a conditional breakpoint to simulate it. Define a function like this in your code:
int clear_console()
{
NSLog(#"\n\n\n\n\n\n\n\n");
}
Then, when you want to clear the console just add a breakpoint before the NSLog with this condition:
Condition: 1 > 0
Action: Debugger Command expr (int) clear_console()
Options: Automatically continue after evaluating Check it to skip the pause.
Tested with Xcode 4.3.2 and lldb.
Previous answer:
AFAIK, no, there isn't.
Just in case you're not doing it yet, you can create custom macros to format the output to highlight what you want.
Define macros like this:
#define CLEAR(...) NSLog(#"\n\n\n\n\n\n") /* enough \n to "clear" the console */
#define WTF(...) CLEAR();NSLog(#"!!!!!!!!!!!!!!");NSLog(__VA_ARGS__)
#define TRACE(__message__) NSLog(#">>>>>>>>>>>>>>> %# <<<<<<<<<<<<<<<<<<<", __message__)
Then:
WTF(#"This should't be here object: %#", theObject);
...
TRACE(#"Start Encoding");
...
It's not what you want but it pretty much solves the problem. You'll end up with your own set of macros with custom prefixes easily scannable in the console output.
I'm trying to profile a Perl script, but CORE::sleep gobble all the space (and time) of my report.
How can i tell NYTProf to ignore sleep calls ?
Assuming we have the following script :
sub BrandNewSubroutine {
sleep 10;
print "Odelay\n";
}
BrandNewSubroutine();
I want to get rid of the following line of the report :
Exclusive Time;Inclusive Time;Subroutine
10.0s;10.0s;main::::CORE:sleepmain::CORE:sleep
(opcode)
Edit: Using DB::disable_profile() and DB::enable_profile() won't do the trick, as it add sleep time to BrandNewSubroutine Inclusive time.
Thanks in advance.
I'd suggest either wrapping the calls to sleep (possibly by use of method mentioned in perlsub) with DB::disable_profile() and DB::enable_profile() calls (RUN-TIME CONTROL OF PROFILING in NYTProf documentation), or post processing the report to remove the offending calls.
CORE::accept is already ignored in the way you'd like CORE::sleep to be, so the mechanism is already in place. See this code in NYTProf.xs:
/* XXX make configurable eg for wait(), and maybe even subs like FCGI::Accept
* so perhaps use $hide_sub_calls->{$package}{$subname} to make it general.
* Then the logic would have to move out of this block.
*/
if (OP_ACCEPT == op_type)
subr_entry->hide_subr_call_time = 1;
So with a little hacking (OP_SLEEP==op_type || OP_ACCEPT == op_type) you'd be able to ignore CORE::sleep in the same way.
I'd accept a patch to enable that as an option.